Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

'Vanish' Makes Sensitive Data Self-Destruct

Soulskill posted more than 5 years ago | from the also-doesn't-appear-to-be-a-fire-hazard dept.

Security 171

Hugh Pickens writes "The NY Times reports on new software called 'Vanish,' developed by computer scientists at the University of Washington, which makes sensitive electronic messages 'self destruct' after a certain period of time. The researchers say they have struck upon a unique approach that relies on 'shattering' an encryption key that is held by neither party in an e-mail exchange, but is widely scattered across a peer-to-peer file sharing system. 'Our goal was really to come up with a system where, through a property of nature, the message, or the data, disappears,' says Amit Levy, who helped create Vanish. It has been released as a free, open-source tool that works with Firefox. To use Vanish, both the sender and the recipient must have installed the tool. The sender then highlights any sensitive text entered into the browser and presses the 'Vanish' button. The tool encrypts the information with a key unknown even to the sender. That text can be read, for a limited time only, when the recipient highlights the text and presses the 'Vanish' button to unscramble it. After eight hours, the message will be impossible to unscramble and will remain gibberish forever. Tadayoshi Kohno says Vanish makes it possible to control the 'lifetime' of any type of data stored in the cloud, including information on Facebook, Google documents or blogs."

cancel ×

171 comments

Sorry! There are no comments related to the filter you selected.

Copypaste (5, Insightful)

sopssa (1498795) | more than 5 years ago | (#28771069)

'Our goal was really to come up with a system where, through a property of nature, the message, or the data, disappears,'

And yet after a copypaste or screenshot it wont disappear anywhere.

Re:Copypaste (3, Interesting)

binaryspiral (784263) | more than 5 years ago | (#28771145)

This could be the next step in actually having secured, signed, digital copies.

I could see a variation of this made available for official documents that need to "phone home" for decription. If the document is somewhere its not supposed to be - scambled.

Of course there are many ways to circumvent this - but I'm tired of faxes being legally more viable than anything digital.

Re:Copypaste (1, Funny)

sopssa (1498795) | more than 5 years ago | (#28771217)

This is actually a good idea. Now just add it to sms's, so I can "cancel" all the text messages I've sent to my ex the night before :)

Re:Copypaste (3, Funny)

CannonballHead (842625) | more than 5 years ago | (#28771523)

You should suggest it to gmail. After all, they already have a way to change the timestamp of the e-mail [google.com] you sent so it looks like you sent it earlier than you did, why not just delete e-mails you've sent no matter where they are!

Re:Copypaste (1)

ls671 (1122017) | more than 5 years ago | (#28771995)

Just look at the dates in the server headers in the message source if you need to catch somebody trying to fool you. Client headers have been very easy to falsify since the beginning of email. (e.g. From:, Date:, Subject: , etc...)

Re:Copypaste (1)

ubergamer1337 (912210) | more than 5 years ago | (#28772117)

WOOSH!

Re:Copypaste (0)

Anonymous Coward | more than 5 years ago | (#28772737)

The link was to an april fools joke Google did a while back. Read it, it was enjoyable.

Re:Copypaste (0, Offtopic)

sumdumass (711423) | more than 5 years ago | (#28772093)

So your one of those people who pick fights to break up for a short time so cheating isn't really cheating too. I generally prefer to do it over the phone rather then by SMS, I suppose that just seems cold for me.

Re:Copypaste (0, Offtopic)

bluefoxlucid (723572) | more than 5 years ago | (#28773091)

ever consider just asking? Last girl that asked me out OFFERED this as a condition of our relationship. (I don't do relationships anyway, so I turned her down)

Re:Copypaste (0)

Anonymous Coward | more than 5 years ago | (#28771637)

Secure signed digital documents are already possible and work very well. You sign the document with your private key and you're good to go. The actual mechanism varies but the effect is the same. This can not be hacked other than someone getting your private key (or breaking the algorithm you used). If someone tampers with the document then it won't verify no matter what. The signature goes to a specific set of data that can't be changed and your public key will verify that the signature is in fact yours.

It way, way more secure and provable than fax and more secure than whatever stupid scheme this self-destruct thing is.

Re:Copypaste (1)

element-o.p. (939033) | more than 5 years ago | (#28772821)

Unless you live in England and the government decides to force you to hand over your encryption key [arstechnica.com] . With Vanish, you *can't* hand over the encryption key because you never had it in the first place.

<pedantic>
Unfortunately, TFS -- and to a lesser extent, TFA -- seems to be ripe with exaggerated claims: "'Our goal was really to come up with a system where, through a property of nature, the message, or the data, disappears.'" and "After eight hours, the message will be impossible to unscramble and will remain gibberish forever."

No. Unless I am missing something from TFA, it is like any other "secure" encryption scheme: merely very, very difficult to break. Given a fast enough computer -- or a large enough cluster of computers working together -- it can be cracked. The only thing Vanish protects against is someone stealing the encryption key from your PC.
</pedantic>

Re:Copypaste (1)

Foofoobar (318279) | more than 5 years ago | (#28772639)

Not really. For it to be useful it would need to be stored and retrieved according to government communications storage standards for companies. All communications need to be able to be stored and retrieved in the case of an investigation or subpoena or other such issues not only regarding your company but your clients as well and all persons you communicate with as a point of business.

Re:Copypaste (5, Informative)

Anonymous Coward | more than 5 years ago | (#28771175)

That's not what this is intended to prevent. Of course the intended recipiant can read it. They could even write it down on a piece of paper.

The same message however, may have been cached in many other places. This scheme is intended to prevent it's retrieval by other parties at a later date.

Re:Copypaste (2, Insightful)

QX-Mat (460729) | more than 5 years ago | (#28771369)

So this is really just a very obfuscated way of achieving what DRM providers have been trying to [favourably] do when they (willfully) allow their authentication services to die or go the companies hosting them plunge into insolvancy.

And to think people thought we were crazy when we warned them that the above DRM 'technique' was a bad idea for consumers from the get go. Pitty "a do over" or repurchase isn't a very good business plan for message encryption -

"Sorry about this, can you send me your email from last week since it's expired now and I need to check up on a few things?"
"No can do, we didn't actually mean anything we said in it. But we didn't lie either. Got proof?".

Sad that it works for media formats.

Just imagine if we allowed the reasons behind why we went to war or how the recession occured to expire like this! Blame would be apportioned in terms of aquiessence rather than proof, "Yes sir, it's definitely not our fault, since we have no records of that - and there's no point in looking since all the keys have expired! If only it had crossed our minds a little sooner, we could have looked at our records when it was politically damaging..."

Re:Copypaste (3, Insightful)

NotQuiteReal (608241) | more than 5 years ago | (#28771387)

heh - the Print Screen button is a terrorist tool!

Re:Copypaste (1, Informative)

Anonymous Coward | more than 5 years ago | (#28771389)

And yet you obviously didn't RTFA.

scattered across a P2P system (1)

192939495969798999 (58312) | more than 5 years ago | (#28771475)

I didn't realize that P2P systems are known for making a piece of information unavailable once it is scattered across that P2P system, especially encryption keys and such. No one gets stuff like that on P2P networks, why would they do that?

Re:scattered across a P2P system (1)

vertinox (846076) | more than 5 years ago | (#28771707)

I didn't realize that P2P systems are known for making a piece of information unavailable once it is scattered across that P2P system, especially encryption keys and such. No one gets stuff like that on P2P networks, why would they do that?

I think the authors were thinking of the the issue of where a torrent goes away once people stop seeding it once the original software is obsolete.

I mean can you find a working torrent of Photoshop 5 these days?

Same difference.

Disappearing Inc answered that question also (0)

Anonymous Coward | more than 5 years ago | (#28772473)

Back during the boom, there was a company called Disappearing Inc. that provided a similar kind of service. (I don't know if they still exist, but they did get bought by somebody with a less cool name...) They came and talked to a Cypherpunks meeting, and their explanation was "We need to be really clear about what problems we're trying to solve and what problems we're not trying to solve. We're trying to let people who want to cooperate with each other protect the information they want; trying to protect information for people who don't want to cooperate would be snake oil." Their target market was corporate data retention.

Their system did key management as a service, with document readers that fetched a key and decrypted the document for you to read. They'd delete keys after whatever date you specified (typically a month or two, or in response to a delete message.) They were US-based, and if they received a subpoena/warrant for information that their lawyers thought was ok they'd provide it, but if they'd already destroyed a key, they didn't have it backed up anywhere.

Re:Copypaste (1)

SlashDread (38969) | more than 5 years ago | (#28772945)

The goal is convenience for the lazy privacy consious. The goal is to prevent a 3d person to read it (at a later time), not the actual users. Consider a nifty trojan that reads your screen in real time, this system wont beat that.
Said that, copypast means nothing: "you mean you typed this text and now pretend is was send through this system?" gosh. Likewise screenshots mean nothing.

Let's not kid ourselves (5, Insightful)

Bruce Perens (3872) | more than 5 years ago | (#28771073)

If the decryption key is ever available to the browser, a modified version of the tool could store it and decode the document forever.

Re:Let's not kid ourselves (5, Insightful)

Eevee (535658) | more than 5 years ago | (#28771123)

No disrespect, but read the article. It explicitly states that this is not designed to keep the parties from saving the information.

It is technically possible to save information sent with Vanish. A recipient could print e-mail and save it, or cut and paste unencrypted text into a word-processing document, or photograph an unscrambled message. Vanish is meant to protect communication between two trusted parties, researchers say.

We already have better tools for that (0)

Anonymous Coward | more than 5 years ago | (#28771159)

Hell, it's practically the reason we invented Public Key Crypto (TLS, etc).

Re:We already have better tools for that (3, Insightful)

Eskarel (565631) | more than 5 years ago | (#28771247)

True, however, in the many years between the invention of Public Key Crypto and today, no one has come close to being able to come up with a way to easily and automatically distribute the keys that doesn't rely on some third party having all of them on file.

There's a reason that encrypted e-mail is pretty non-existent and it's because key management remains unsolved. Manually passing your self generated keys back and forth is all well and good, but it's not all that scalable, and most folks don't know how to do it. I don't know if this works any better mind you, it's probably really more of a nifty trick/experiment, but pretending that Public Key Encryption has solved the secure communication problem is at best naive.

Re:We already have better tools for that (1, Troll)

FnH (137981) | more than 5 years ago | (#28771783)

And now Vanish is the trusted third party .. I'll stick with Public Key Crypto.

Whatever the reasons public key encryption hasn't taken off (too much effort, no perceived threat, ...), it will be those same exact reasons that will prevent Vanish from taking off.

Re:We already have better tools for that (1)

sckeener (137243) | more than 5 years ago | (#28772361)

exactly. Encrypting emails is trivial inside a company, but practically non-existent when dealing with people outside the company. That said we have company policies that state that everything sensitive in nature needs to be encrypted. Thus on a quarterly basis we have a discussion that goes no where because the options don't exist to make this policy a realistic reality.

Re:Let's not kid ourselves (1)

Slashdot Suxxors (1207082) | more than 5 years ago | (#28771185)

If it's supposed to be between two trusted parties then what's the advantage of this over PGP/GPG? A fancy "vanish" button? Someone enlighten me.

Re:Let's not kid ourselves (1, Troll)

John Hasler (414242) | more than 5 years ago | (#28771237)

> A fancy "vanish" button?

Yes. The average PHB might just barely have the intellectual capacity to deal with that.

Re:Let's not kid ourselves (2, Informative)

MeanMF (631837) | more than 5 years ago | (#28771255)

If an attacker captures the encrypted message, they could save it and decrypt it at a later date if they are somehow able to obtain the recipient's key. With this system, the key is (supposedly) completely gone and not even the recipient can decrypt the message again.

Mod Parent Up - that's exactly what it does (1)

billstewart (78916) | more than 5 years ago | (#28772567)

Disappearing Inc had a similar service back during the boom. They'd manage document keys for you, and you'd read the document using a reader that fetched a document key from their servers and opened a copy for you but didn't give you the actual key. When the key expired (based on whatever date you set with them, or a delete message), they'd delete the key, so nobody could decrypt the document later.

Re:Let's not kid ourselves (1)

TheCycoONE (913189) | more than 5 years ago | (#28771257)

Even if one of the parties systems are compromised, the hacker won't be able to find some key that will allow them to decode the messages.

Re:Let's not kid ourselves (5, Interesting)

mlts (1038732) | more than 5 years ago | (#28771337)

One advantage I see is that after the Alice sends Bob the message and Bob has it stored, then the copies of the message floating around on the Internet become completely non-decryptable after the time limit has expired. Even if a third party manages to decode or obtain Bob's private key, it won't do them any good in obtaining the text; the attacker would have to attack either Alice or Bob's endpoint, which is a lot harder than just passively sifting stuff sitting on a server with unknown security.

Vanish does the same thing that cryptographic tokens do. Both limit the window of attack on something. Where a smart card would limit guesses of a key's PIN to 3-5, Vanish limits the time of attack of a message to 8-12 hours.

Re:Let's not kid ourselves (2, Interesting)

EdZ (755139) | more than 5 years ago | (#28771415)

If I'm guessing correctly, what's sent is essentially the cyphertext and a series of URLs that point to what makes up the key (e.g. go to page x, take every third character from the 27th line, etc). The idea being that the pages chosen should change often enough that anyone who intercepts the message, and LATER attempts to decypher it, will be unable to.
Basically, the only time this will offer protection is when the following conditions are all met:
a) The URLs chosen are not cached anywhere
b) The URLs chosen cycle regularly and randomly (the random part is important, and unlikely)
c) The message is NOT read by the attacker until after the key has disappeared. This will probably only occur if the keylinks & cyphertext are posted on a forum or similar, and which the attacker visits later. If the message is emailed/IMed/etc, then intercepting it at the time would make automatic decyphering trivial.
This all hinges on the assumption that the service does not hinge on a set of specially operated key generating servers (loss of which would prevent the service from operating). Such a service would provide properly randomised key fragments, but faces other issues. The fragments must be publicly accessible, change only after an 'acceptable' time period (implied to be a few hours), and remain constant for these few hours. This would make caching of the keys trivial. And would still not prevent decyphering upon interception within the time limit.
I suppose the key servers could require a key as part of the message itself to provide the correct key fragment, but this would only solve the caching attack, not interception.

Re:Let's not kid ourselves (1)

John Hasler (414242) | more than 5 years ago | (#28771713)

Each key fragment should deleted the first time it is accessed. Instead of using pre-existing P2P networks build a special-purpose self-organizing network of all the machines with Vanish running on them which could implement the improvements you suggest.

Re:Let's not kid ourselves (1)

david_thornley (598059) | more than 5 years ago | (#28772237)

Keys deleted on first access? That's a great way to guarantee that the mail will get through.

Re:Let's not kid ourselves (2, Funny)

dmdavis (949140) | more than 5 years ago | (#28772205)

No disrespect, but...

woah... courtesy? You must be new here. You were supposed to say "Why don't you RTFA, you mouth-breathing buffoon." I realize that it's Bruce Perens you were responding to, but this is Slashdot. We have standards here!

Re:Let's not kid ourselves (1)

dcollins (135727) | more than 5 years ago | (#28772263)

"Vanish is meant to protect communication between two trusted parties, researchers say."

That doesn't make any sense. Just use regular encryption for that.

Re:Let's not kid ourselves (1)

Facegarden (967477) | more than 5 years ago | (#28771853)

If the decryption key is ever available to the browser, a modified version of the tool could store it and decode the document forever.

Well, I was thinking about this, and the real idea is to prevent people who never originally saw the message from reading it down the road. If i send you a message, and then it scrambles, no one hacking into your e-mail later will be able to read it (barring cracking the scrambling system itself, obviously). It's not to prevent YOU from copying the message, it's to prevent new people from reading it after the 8 hour window is up.
-Taylor

Re:Let's not kid ourselves (1)

v1 (525388) | more than 5 years ago | (#28772045)

I was thinking about this and the only way they could engineer it to work even remotely like they advertise is if someone wanting to read the material forwarded it along with their 1/2 of the key to the 3rd party. The 3rd party then combines their 1/2 of the key with the provided, decrypts the data, and sends it back to the requestor. As long as the requestor does not maintain a copy of the cleartext, (as several have quipped with
"screenshots?") then this would work. Once the 3rd party no longer has their 1/2 of the key, the data is irrecoverable. This however requires that only the 3rd party have a copy of their 1/2 of the key. Otherwise someone could cache a copy of the keys and as long as they have the keys and can hook up with a requestor, the data continues to be recoverable.

It's broken worse if the requestor requests the key from the 3rd party and gets it, because they themselves could cache a copy of the key just the same. But that's not fairing any better against the "screencapture" argument.

This isn't going to work. Another approach is to keep the 1/2 of the key in the cloud, but after a preset time, to flood the cloud keystore with plausible keys, too many to practically sort through to figure out which was the correct key. This only partly unbreaks the problem though.

The only example of anything even remotely similar having a "future-breaking" effect is in verifying identity. Create a key for say, year 2099. Make a key for 2098 and use 2099's key to sign it. Repeat the process down to current. Release all public keys for 2009-2099 to the public domain. Sign a document with key from 2009. You can be verified as the signer of the document. But on jan 2010, release the private key for 2009 into public domain and start using the key for 2010 to sign. Anything signed in 2009 can't be verified to be you anymore because the private key for 2009 is in public domain and records plausibly could have been altered. You can repeat this process until you reach the end of your chain of keys. There's no reason to expire keys on a certain date either, you could roll up 10,000 of them in this manner and expire them anytime you wanted or needed to, and as long as the entire set of keys remains available, anyone can verify your identity as long as it's signed with a key that has not yet been released. Done properly, the entire keyset could be in one document/package, as a giant chain of trust. Technically the only key they need to have that matters is your "root" 2099 public key because it can be used to verify the authenticity of any of your other public keys.

Though that breaks the past. You can't break the future

Obvious application (5, Funny)

Dice (109560) | more than 5 years ago | (#28771099)

Dear Alice,

Do you want to go to the dance with me?

[ ] YES
[ ] NO

Love,
Bob

(Message will self-desctruct 1 minute after dance starts.)

Re:Obvious application (1)

ShieldW0lf (601553) | more than 5 years ago | (#28771401)

More like

(Message will self-destruct 1 minute after someone from the mailing list I sent this to says yes)
(someone?)
(anyone?)
(hello?)

Re:Obvious application (4, Funny)

Eevee (535658) | more than 5 years ago | (#28771581)

Dear Bob,

No, but I'm sure that Eve would say yes if you asked her.

Alice

PS: Please don't ever mention this message to me in the future...and if you do, don't be surprised if I, umm, have forgotten receiving it.

Re:Obvious application (5, Funny)

bluefoxlucid (723572) | more than 5 years ago | (#28773163)

How about a 3-way with both Alice and Eve?

Oh yeah. I had the balls to ask.

Good Morning, Mr. Phelps (1)

mcgrew (92797) | more than 5 years ago | (#28772307)

Should you decide to accept this assignment...

Time changing mutation strings ? (0)

Anonymous Coward | more than 5 years ago | (#28771121)

read this in one of Dan Browns novels
Sounds simliar to time changing mutation strings ? I thought there wasnt a reliable way to do this ever . I mean something has to understand what the keys are at any point in time.

Re:Time changing mutation strings ? (1)

EricJ2190 (1016652) | more than 5 years ago | (#28772657)

Please don't take anything you read in Digital Fortress seriously. It is a great thriller, but from a technical standpoint it is full of crap.

Your mission, if you choose to accept it... (0)

Monkeedude1212 (1560403) | more than 5 years ago | (#28771129)

Is to assist this open source project!

Then make this message self destruct.

I needed that 20 years ago (0)

Anonymous Coward | more than 5 years ago | (#28771137)

for all the flames I posted on Usenet

So that's what's been happening (5, Funny)

hwyhobo (1420503) | more than 5 years ago | (#28771157)

After eight hours, the message will be impossible to unscramble and will remain gibberish forever

I think corporate VPs have been using this tool for years, with the delay trigger set to "0".

Just use Freenet... (1, Funny)

ShaunC (203807) | more than 5 years ago | (#28771193)

...everything disappears off there pretty quickly already.

Adaptability (3, Funny)

arizwebfoot (1228544) | more than 5 years ago | (#28771219)

I wonder how I could adapt this to conversations my wife has with me, since she reminds me of stuff I said 20 odd years ago?

Re:Adaptability (2, Insightful)

drxenos (573895) | more than 5 years ago | (#28771425)

The only answer to that problem is lots and lots of jewelry.

Re:Adaptability (1)

rootofevil (188401) | more than 5 years ago | (#28772087)

or a new wife.

depends whats more expensive, the jewelry or the divorce.

Re:Adaptability (2, Insightful)

element-o.p. (939033) | more than 5 years ago | (#28772883)

The only answer to that problem is lots and lots of jewelry.

Let me know how that works for you. Seems to me like you are training your wife to bring up something again every time she wants a shiny new trinket...

Privacy Assurance == DRM (1)

internic (453511) | more than 5 years ago | (#28771265)

If the software allows the user to view the plain text, then it can be copied, so I don't see how this would really ensure it disappears. While I would love to be able to have social networks or cloud computing that could guarantee privacy by having technological measures to prevent the dissemination of private information, I think that problem is exactly the same one DRM tries to solve. And that is why it is doomed to fail. The only way it could really hope to succeed is in a world of ubiquitous "trusted computing" where the computer (and any other recording devices) ultimately will not carry out user commands to copy the data (or copy the output from the "analog hole". In the current world, such a scheme is doomed to fail, and the world where it would work sounds like a dystopian future to me.

All that being said, perhaps it can be used to prevent authentication of the information? Somehow the digital signature could no longer be read, so you could show a copy of a document but not demonstrate that it was really created by the author. It's not clear to me whether that's possible.

!DRM, TTL instead (0)

Anonymous Coward | more than 5 years ago | (#28771465)

You're thinking about it wrong. It is basically a TTL (Time To Live) tool for data just in case it ends up in some place it wasn't meant to be. Hence the trusted two parties part.

Re:Privacy Assurance == DRM (2, Informative)

vertinox (846076) | more than 5 years ago | (#28771757)

I think that problem is exactly the same one DRM tries to solve.

Actually the authors specifically does not prevent the recipient from copying as it was not their intention. It was to prevent man in the middle attacks of people who were not supposed to be copying in the first place.

Application would be video streaming (1)

Absolut187 (816431) | more than 5 years ago | (#28771267)

Looks like the studios may soon use the peer-to-peer concept against copiers.

As noted above, this isn't really useful for email - it would be easily defeated by copy/paste or screenshot, etc.

But it is viable for things like movies. If you can only decrypt a movie stream while its streaming, it makes it harder to keep a copy of it.

Probably not impossible, but harder.

Not useful for DRM (2, Interesting)

swillden (191260) | more than 5 years ago | (#28771279)

I see someone has tagged this article with "drm", but this isn't a usable technique for DRM. This is an interesting technique for creating a "disappearing" decryption key, but it only works if no one bothers to retrieve/reassemble the decryption key before it disappears. If the recipient retrieves the key while it still exists, he can save the key and decrypt the message at any time. Or he can retrieve the key, decrypt the message and save that. The most obvious application for this, I think, is forward security. As long as the recipient doesn't save a copy of the decrypted message or the decryption key, the message would become unreadable -- to anyone -- after a short period of time. I need to read the details to see if this would be useful in some real-world setting, or if it's of academic interest only.

Re:Not useful for DRM (3, Insightful)

Bruce Perens (3872) | more than 5 years ago | (#28772359)

It's because the tool itself would need to be DRM-locked if you wanted to enforce the time expiration on the intended recipient.

What? (2, Funny)

wjousts (1529427) | more than 5 years ago | (#28771291)

After eight hours, the message will be impossible to unscramble and will remain gibberish forever.

Most of my messages are gibberish to begin with. No scrambling needed!

Re:What? (2, Funny)

mcgrew (92797) | more than 5 years ago | (#28772439)

OMFG, my ex-wife is posting at slashdot!

Re:What? (1)

bertoelcon (1557907) | more than 5 years ago | (#28773233)

But after you scramble gibberish, it becomes normal.

Corporate crimes (5, Insightful)

wjousts (1529427) | more than 5 years ago | (#28771365)

I can see this being useful for corporations that want e-mails to be destroyed before they can be used against them in court. Sure you could take a screen shot or copy/paste the text before the e-mail is permanently destroyed, but can you prove that your copy wasn't tampered with? Can you prove that was what the e-mail originally said? Plausible deniability!

Re:Corporate crimes (0)

Anonymous Coward | more than 5 years ago | (#28771675)

This isn't very interesting for corporations in the manner you suggest. One, in the event of a civil action "plausible deniability" is not the rule, "preponderance of evidence" is. In the event of a criminal case they would run afoul of data retention laws and would be no different than shredding files and is achievable by less convoluted means.

This *could* be handy for spies. You can communicate encrypted and (potentially) be left with a destroyed message in short order. You could not be forced or coerced after the fact to decrypt it.

Re:Corporate crimes (1)

fishbowl (7759) | more than 5 years ago | (#28771873)

>Plausible deniability!

An interesting word salad that is not nearly as useful in civil court as some would like you to believe.

Plausible deniability is a euphemism for "perjury you might get away with."

I often tell my employers that if called to testify on *anything* I will simply tell the truth, and that they should operate accordingly and make rational choices with that in mind.
Sometimes they seem to think I'm joking about this. I assure you that I am not.

Re:Corporate crimes Really? (1)

davidsyes (765062) | more than 5 years ago | (#28771937)

I thought we (or at least very developed countries) already had laws on the books to combat corruption, fraud, embezzlement, collusion, anti-competitiveness, tax evasion/avoidance, and so on. Why would the existence or viability of "Vanish" vaporize culpability or liability or such. The absence of information corroborating corruption won't be the only way to bust crooked or derelict CEOs and company. Absence of time stamps, gaps in file queues, loose lips, and other things will (or can) aid in their undoing if an investigation commences.

Besides, anyone wanting to make sure their CEOs are held to account just needs to be in IT, or have a DIRECT LAW ORDER from the federal government "YOU ARE ****EXPLICITLY**** DISALLOWED PRIVILEGE TO USE "VANISH" FOR ANY BUSINESS, COMMERCIAL, ECONOMIC, PAYROLL, PAY-FOR-WORK, MEMORANDUMS OF UNDERSTANDING, LETTERS OF INTENT, OR THEIR LOGICAL EXTENSIONS OR PREDECESSOR ACTS. END OF STORY FOR YOU."

And, then let the legal chicanery and expensive case filings begin.

Re:Corporate crimes (3, Insightful)

westlake (615356) | more than 5 years ago | (#28772399)

Plausible deniability!

The judge and jury get to decide what is plausible.

It won't look good if the erasure violates standard practice or professional guidelines, legal obligations or existing corporate policy.

In criminal law, a guilty verdict demands proof beyond a reasonable doubt.

That does not mean that every piece of evidence has to carry the same weight - only that the evidence when viewed as a whole is damning.

If the state's witness performs credibly on the stand, that will carry over to whatever documents he is asked to describe and identify.

"Plausible denial" is a world of hurt.

Vanish++ (3, Funny)

Mysund (60792) | more than 5 years ago | (#28771385)

If you buy the Vanish++ package, you get an additional package of superglue, to glue the printscreen button stuck.

This is not free software (1)

Anonymous Coward | more than 5 years ago | (#28771419)

See their license at this page [washington.edu] :

1. Software may not be modified except for personal, educational or informational purposes.

This is not free software, nor is it open source.

Re:This is not free software (1)

gparent (1242548) | more than 5 years ago | (#28772365)

http://vanish.cs.washington.edu/download_src.html [washington.edu]

Are you blind? It's not free but definitely open source.

Re:This is not free software (1)

93 Escort Wagon (326346) | more than 5 years ago | (#28772533)

http://vanish.cs.washington.edu/download_src.html [washington.edu]

  Are you blind? It's not free but definitely open source.

Well, to a true FOSS zealot it's not free, nor open source, unless it fits THEIR definition of "free software". Ironically their definition is sorta 1984'ish, with the words meaning something different than their literal meaning.

Also, for purity's sake you should have capitalized "Free" in this context.

Re:This is not free software (1)

Miseph (979059) | more than 5 years ago | (#28772841)

It is both "free as in beer" and open source (the source code is available for all to see), it just doesn't let you do certain things with it (ie. commercial use).

Also, from their FAQ:

"For (1) [Vanish core], we have chosen to, at least for now, use a UW-specific Academic License. Our choice of license is based largely on the fact that Vanish is still an experimental research prototype. You'll notice a number of terms and conditions with this license. Just so that there are no unexpected surprises, our license highlights the fact that Vanish will destroy data (which is not something one finds in normal applications). Also, as we note elsewhere in this FAQ, Vanish raises interesting questions from a legal perspective. Our license discusses how users must assess for themselves the legal implications of Vanish for their own situations. See the license itself for all the details."

Doesn't seem so nefarious in that context.

Just what we need...another way to lose data (1)

MpVpRb (1423381) | more than 5 years ago | (#28771437)

I can just imagine the bugs, accidents and outright stupidity that will lead to millions of users asking "where did my data go?"

At last... (4, Funny)

quarkoid (26884) | more than 5 years ago | (#28771577)

Finally, an article in my area of expertise. Now this is likely to earn me +5 insightful, interesting and everything else.

So, why is Vanish useful to us?

Well... [BEGIN VANISH]u5vw7b658we77kw4657865v87zb68e7y678ctr63or63o7t6ox9587x4ygfiouhx
eo84yre kl76v5los79y6to89xep89x7e4v6eotyl9e84lbvr8xy76ebl9txevl9r8
ygnl8odvr,i8xeyvti8seybvto eby5tli8xevynlr8n776vsot7vnl9xe84nyu .lwaje
aowpibtulieut,iwvy,o39u dryswrl9uzfna484ytlo8cwjnlv ig78wfp9cnusgl8w
3n4aly8u .og8unl98nst.oby487rw;zbv5l936tlisd rnzsche.ldnj ekqb;wv4ioa
ur.,zwjsehg f,vhlfiawvutileuklrla wucbtrqil37ctlasehjctn;laiwuerciluqw3ybt
ow875ntliu awu[9c57st8nzwci4ycrnhseu6go38ny cfukbtw347v6f5o93vsb
y to9y347icr yisuryctw 37bt6l9s38 ucr,ugbvt6o8w 3nyu.oulv87vg[END VANISH]

I think we can all agree with that.

Nick.

Re:At last... (4, Funny)

vertinox (846076) | more than 5 years ago | (#28771789)

o39u dryswrl9uzfna484ytlo8cwjnlv ig78wfp9cnusgl8w
3n4aly8u .og8unl98nst.oby487rw;zbv5l936tlisd rnzsche.ldnj

What?!

How dare you sir! My mother is a saint!

Re:At last... (2, Funny)

A. B3ttik (1344591) | more than 5 years ago | (#28771939)

y to9y347icr yisuryctw 37bt6l9s38 ucr,ugbvt6o8w 3nyu.oulv87vg

Ia! Ia! Cthulhu ftagn!!

Re:At last... (0)

Anonymous Coward | more than 5 years ago | (#28772443)

Seems like some really bad crypto. Not only is it all lowercase, 30% of the characters are in the group (7, y, u, t, 8, l).

Re:At last... (1)

johnny0099 (1068928) | more than 5 years ago | (#28773013)

They should rename it to Forrest Dump.

"And that's all I have to say about that."

how is this different from a smart card? (1)

jipn4 (1367823) | more than 5 years ago | (#28771583)

This can be done pretty easily with a smart card: it only gives out the key for a limited amount of time. I suppose you have to trust the manufacturer of the smart card, but you also have to trust the manufacturer of the PC you're reading the message on, and its OS and ...

Hey hey! (1)

SGDarkKnight (253157) | more than 5 years ago | (#28771611)

Sounds like we would simply need the device listed in paragraph 3, sentence 5 here [wikipedia.org]
  in order to decrypt it :-)

Quotation reference mistkae (1)

aalevy (1602695) | more than 5 years ago | (#28771689)

The quote 'Our goal was really to come up with a system where, through a property of nature, the message, or the data, disappears' should actually be attributed to Prof. Henry Levy, not Amit Levy. The confusion was probably caused by the press release only refers to the last name.

Let's not forget Copy Paste (1)

strangeattraction (1058568) | more than 5 years ago | (#28771699)

So I get a copy and it gets cached or copy and pasted somewhere else. Busted. It is of limited use only for people that agree the data should be destroyed.

Who gets to read it? (1)

danking (1201931) | more than 5 years ago | (#28771837)

I am confused so hopefully someone can shed some light. They say there is no need to swap public keys with the person you are writing the message to. Does this mean anyone with the tool in Firefox can decode your message? Is there some way to specify who the reading parties are? That I am a little confused about and couldn't find any info about it in the articles. Hopefully someone can clear it up.

Re:Who gets to read it? (1)

clone53421 (1310749) | more than 5 years ago | (#28772155)

Seems to be so... how else could you encrypt, for example, a Facebook status and allow "anyone" (anyone on your friends list) to decrypt it within the time window before it "self-destructs"?

Re:Who gets to read it? (1)

stuffeh (1108283) | more than 5 years ago | (#28772211)

Well, to get around the problem you're suggesting, all they would need to do is to use the "generalized key" that is out there for the whole public, run it through a key generator scheme like the Diffie-Hellman key exchange protocol and you've got a brand new key that uses a public and private key to be secure. I didn't read the article, so I've no idea how Vanish addresses this problem, but it is a very easy one to solve. Anyone in cryptography knows about the Diffie-Hellman algorithm and how well it works against Eve, however if Oscar were involved, that's another story. (Eve just listens, Oscar intercepts and modifies the packets).

why distribute the keys, just destroy them (0)

Anonymous Coward | more than 5 years ago | (#28771905)

Not sure what this research will achieve. Message is available at both ends. So it can be copied and stored in plain text. Only way to destroy the message is to both sides agree on it and destroy it. When that happens both sides can agree to destroy the keys as well.

Did we need a story for an answer (1)

JTsyo (1338447) | more than 5 years ago | (#28771919)

for the one further down where the guy wanted his data gone if the laptop was stolen. slashdot [slashdot.org]

Some ISPs (1)

arazor (55656) | more than 5 years ago | (#28771941)

Some ISPs have already made using P2P against terms of service. With this program I can governments just flat out banning all P2P as "terrorist tools".

50% Tech, 50% Hope (4, Informative)

Anonymous Coward | more than 5 years ago | (#28771965)

The core idea behind Vanish, if you dig 6 links deep to the actual technical information, is that nodes on a P2P network come and go. Therefore, if you break up the decryption key, and scatter it on the network, eventually some of those nodes will go away, and the key won't be recoverable. Apparently, the authors have some clever (unmentioned) trick to control the timing on this to a limited extent.

So, obviously, this doesn't work. It relies on the worst kind of trust -- trust of a P2P network. If the network is compromised, the data is permanently decryptable. Better yet, it relies on a P2P network to continue behaving the same -- if all nodes suddenly had 99% uptime, this would entirely stop working. Finally, even if this works, it doesn't make decryption keys "go away" -- it just makes it incredibly difficult for someone who doesn't have the key to obtain it. Anyone who already has the key will have it forever.

Cute. Here's how it works. (5, Informative)

Animats (122034) | more than 5 years ago | (#28771993)

First, as is typical, the Slashdot article is three steps removed from the actual paper [washington.edu] , which is worth reading.

It's kind of cute. What makes it work is that the indexing part of the Vuze platform, which is distributed over a few million user machines, has an 8-hour timeout. After eight hours, otherwise unused entries are purged from cache, like DNS cache expiration. So it's possible to use Vuze for unreliable short-term storage of key-value pairs.

(Normally, the Vuze hash is used as a index to BitTorrent blocks, and if there's a block on a server, the server puts it into the hash and refreshes it periodically, so the block stays indexed. But it's possible to put arbitrary key-value pairs into the distributed hash that have no relationship to BitTorrent blocks. If you put info in the hash and don't refresh it, it goes away after eight hours.)

So the sender generates a key, encrypts the message, spreads the key across some number of key-value pairs on random Vuze clients, sends a message telling what key-value pairs in Vuze contain the crypto key, and deletes the local copy of the key. The receiver gets the message, looks up the key-value pairs specified in the Vuze hash, reconstructs the key, decrypts the message, displays it, and deletes the local copy of the key. The receiving client has to do this every time the message is viewed.

This violates the Vuze terms of service [vuze.com] , incidentally.

Re:Cute. Here's how it works. (1)

aaaaaaargh! (1150173) | more than 5 years ago | (#28772143)

So the sender generates a key, encrypts the message, spreads the key across some number of key-value pairs on random Vuze clients, sends a message telling what key-value pairs in Vuze contain the crypto key, and deletes the local copy of the key. The receiver gets the message, looks up the key-value pairs specified in the Vuze hash, reconstructs the key, decrypts the message, displays it, and deletes the local copy of the key. The receiving client has to do this every time the message is viewed.

Uh...unless the client just saves the plaintext message, of course. So the attacker has to intercept the message within approx. eight hours in order to retrieve the message and then store it forever. There may be scenarios where this can be useful, although I can't come up with one right now.

Re:Cute. Here's how it works. (1)

amateur6 (1597289) | more than 5 years ago | (#28772831)

Amusing point about the Vuze POS.

But SHAME for not marking the PDF as such! Shame, shame to Animats!

Re:Cute. Here's how it works. (1)

CaseCrash (1120869) | more than 5 years ago | (#28773061)

Are you seriously saying you click links on slashdot without first looking at where it's sending you?

Familiar (0)

Anonymous Coward | more than 5 years ago | (#28772015)

This reminds me of a system I saw someone developing several years ago at Critical Security. A message would be encrypted with a key based on Google results for a particular query (the query would be known to both parties). The results changed frequently enough that after a short period, the key was lost forever.

Legal Problem (3, Interesting)

Phrogman (80473) | more than 5 years ago | (#28772173)

Not to put to fine a point on it, companies are supposed to have an established document retention policy that specifies how long they will retain information like email messages. Most email it won't matter but if the contents in any way can be seen as a legal document - i.e. are business related - then destroying them this way might be seen as a deliberate attempt to cover up information by a court. IANAL, but I worked for some in this area, and its remarkably sensitive.

If someone at a company decides to use this tool, unbeknownst to the company and the other party is also using it, then the email becoming garbled and eventually deleted could become a problem should the company ever go to court. The court might require the company to produce a copy of all emails from the company during a given period (say the last 2 years perhaps), and if emails were destroyed in a manner that was not specified by the company retention policy it could cause the court to penalize the company when it fails to produce said emails.

When a company gets sued, its normal for them to place a hold order on the destruction of all documents, so they can't be seen as potentially covering things up. I hope that a tool like Vanish can be toggled to prevent unwarranted destruction, or someone is going to pay big time down the road.

It may seem like a trivial point, until you read of fines in the millions for companies who are unable to produce correspondence they should have preserved legally speaking. Moreover if the garbled email still exists, then the company might be required by the courts to unencrypt it - and if unable to do so, be penalized for that.

The Best Forensics (1)

DaMattster (977781) | more than 5 years ago | (#28772491)

I don't think it is possible to completely make your data vanish. Some of the best computer forensics experts can still get data back even when it has been "government wiped" with random 1s and 0s written to every hard drive sector. This claim is dubious at best.

the answer is "text" (0)

Anonymous Coward | more than 5 years ago | (#28772629)

this story begs for a 'usetextpls' tag...

What's the big deal... (1, Funny)

Anonymous Coward | more than 5 years ago | (#28772641)

My MAXTOR drives have been doing this for years.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>