'Vanish' Makes Sensitive Data Self-Destruct 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."
Copypaste (Score:5, Insightful)
'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 (Score:4, Interesting)
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: (Score:2, Funny)
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 (Score:4, Funny)
Re: (Score:2)
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: (Score:2, Funny)
Re: (Score:2)
No, the girls I keep around are the ones I think I might want to get serious with. I probably couldn't handle them sleeping around and me knowing about it. The one night stands are just that, a quit get your rocks off and be done with it. Sometimes it's to prove a point, sometimes it's because she is that hot. But rarely are they hot and worth keeping as far as I have been able to tell.
Re: (Score:2)
Re: (Score:2)
<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 t
Re: (Score:2)
Use the RAM (Score:2)
And that's exactly the problem here. What keeps me from running that tool in a debugger and grabbing the key once it's reassembled? Worse, what keeps me from reversing the tool to learn its key gathering mechanism and collect the key pieces, assemble them and have the key?
Or hey, how about a really neat idea: How about simply grabbing the decrypted file from memory?
Re:Copypaste (Score:5, Informative)
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: (Score:2)
Re: (Score:3, Insightful)
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
Re:Copypaste (Score:4, Insightful)
Re: (Score:2)
You were appropriately modded insightful instead of funny. 10 years ago, this would have been different.
That's exactly the danger of such "best before..." keys: It makes possible what Orwell could not have engineered any better: It allows you to rewrite history. We've always been at war with Eastasia.
It's even worse than Orwell imagined it: It doesn't even create jobs.
scattered across a P2P system (Score:2)
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: (Score:2)
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.
Re: (Score:2)
The difference here is that nobody wants that information anymore. There is no set expiry date on content in P2P networks. It usually expires once you can get something better, but rarely before that. I'm fairly sure you'll still find copies of Star Wars Kid and Numa Numa, for now, forever.
I'm fairly sure, the more someone wants something to vanish from 'the cloud', the less likely it is to vanish.
Re: (Score:2)
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.
Re: (Score:2)
The goal is to prevent a 3d person to read it (at a later time), not the actual users.
And this it does not provide, or at the very least not ensure. And that's the crucial point about security: Either do or don't. There is little room for 'maybe'.
All you need is one leaked copy. One is enough. Data can be multiplied easily, quickly and cheaply. Ask the RIAA. The threat isn't that millions of people might crack your document. The threat is that one person might and distribute it to those millions.
Re: (Score:2)
Their "property of nature" is their P2P software deleting files that are more than 8 hours old.
It's nothing more than encrypting data and storing the key with an authority of some type, which promises to delete it at a certain time. Except in this case the authority is using their own P2P network to store the keys.
Let's not kid ourselves (Score:5, Insightful)
Re:Let's not kid ourselves (Score:5, Insightful)
Re: (Score:3, Interesting)
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 ch
Re: (Score:2)
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: (Score:2)
Keys deleted on first access? That's a great way to guarantee that the mail will get through.
Re: (Score:2)
You would have to have received the message in order to have the key required to retrieve the first key from the network.
Re: (Score:2, Funny)
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: (Score:2)
"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: (Score:2)
> That doesn't make any sense. Just use regular encryption for that.
"Vanish is meant to protect communication between two trusted parties who are too stupid to deal with the complexities of real encryption."
In other words, the vast majority of business executives and government bureaucrats.
Re: (Score:2)
And that's in what way superior to PGP? If I had to, I'd start cranking out public keys at a rate of 3 per day and I'm there. I don't need to trust their P2P network, though.
Re: (Score:2, Troll)
> A fancy "vanish" button?
Yes. The average PHB might just barely have the intellectual capacity to deal with that.
Re: (Score:3, Informative)
Mod Parent Up - that's exactly what it does (Score:2)
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: (Score:2)
What kept me from reversing their reader, then write a tool that fetched the key and stored it?
Re: (Score:2)
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: (Score:2)
Why bother with the key? When I have one of the participating systems compromised, I grab the plain text message instead.
I'm not going to invest time to find a way through the steel security door if the walls are made of paper.
Re:Let's not kid ourselves (Score:5, Interesting)
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: (Score:2)
I see the weak point in the way the key is "stored". Alice creates a key and sends it into the cloud. Bob has to retrieve the key and apply it without knowing how it really works. That leaves a single question: How does Bob figure out what key to retrieve, and how do you avoid that someone poses as Bob?
Re:We already have better tools for that (Score:4, Insightful)
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: (Score:2, Troll)
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: (Score:2)
Almost certainly true. The point is that saying this is pointless because we've already solved the problem is fundamentally untrue, both because the research for this project has some interesting implications and because the problem is far from solved.
Re: (Score:2)
Re: (Score:2)
What's wrong with company level key collection and exchange of keyrings between companies? Scales fairly well and works great, for us at least.
Re: (Score:2)
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
Sarbanes-Oxley violation. (Score:2)
So a US corporation using this on its internal email (or even receiving email encrypted with this tool) would be in violation of the record-keeping requirements of the the Sarbanes-Oxley Act (unless they decrypted and kept an in-the-clear copy of EVERY such letter that arrived), even if they automatically archive all email they handle.
I bet a number of VPs of IT need a change of pants about now.
Re: (Score:2)
Yeah. So, clearly they aren't part of the intended user base.
Re: (Score:2)
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 thei
Re: (Score:2)
The real issue is not wehter the intended recipient can save a readable copy.The idea is I believe to prevent unintended recipients.
Now how prevent that? As the message will have to have some form of information on how to obtain the crypto key.... How prevent the snooper to find the key if he also has the application????
Somehow plain old PGP/GPG seems a whole lot better
Obvious application (Score:5, Funny)
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: (Score:2)
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 (Score:5, Funny)
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 (Score:5, Funny)
How about a 3-way with both Alice and Eve?
Oh yeah. I had the balls to ask.
Re: (Score:2)
You're proposing a man in the middle attack? :-)
Re: (Score:2)
Should have used diff-hellman!
(noone ever talks about girl-in-the-middle attacks, right?)
Re: (Score:2)
Good Morning, Mr. Phelps (Score:2)
Should you decide to accept this assignment...
So that's what's been happening (Score:5, Funny)
I think corporate VPs have been using this tool for years, with the delay trigger set to "0".
Re: (Score:2)
Adaptability (Score:4, Funny)
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: (Score:3, Insightful)
Re: (Score:2)
or a new wife.
depends whats more expensive, the jewelry or the divorce.
Re: (Score:3, Insightful)
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...
Re: (Score:2)
Hehe... My ex has already applied the reverse.... anything I said more than 3 hours earlier was gone... "You never said that" :-D
Privacy Assurance == DRM (Score:2)
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 "trust
Re: (Score:3, Informative)
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.
Re: (Score:2)
You're right. I actually had to run out just a few minute after the reading the summary and didn't get a chance to RTFA until now. I can see how this could potentially be useful for encrypted communications between two trusted parties to ensure that neither party is later coerced into divu
Re: (Score:2)
Re: (Score:2)
It's a gimmick. You could easily store the key with a central authority instead of a P2P network, exactly the way DRM works now. In fact, I'd much rather the key for messages I send was stored WITH ME so I could be sure it was erased, rather than stored with Joe and Alice's P2P network (we promise we erase stuff! Honest!).
Not useful for DRM (Score:3, Interesting)
Re:Not useful for DRM (Score:4, Insightful)
Re: (Score:2)
It's because the tool itself would need to be DRM-locked if you wanted to enforce the time expiration on the intended recipient.
You'd also have to ensure that there's no way to retrieve the key without the tool. That doesn't seem to be a goal of this research, which is my point.
What? (Score:3, Funny)
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: (Score:3, Funny)
OMFG, my ex-wife is posting at slashdot!
Re: (Score:2)
Corporate crimes (Score:5, Insightful)
Re:Corporate crimes (Score:4, Insightful)
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++ (Score:3, Funny)
If you buy the Vanish++ package, you get an additional package of superglue, to glue the printscreen button stuck.
At last... (Score:5, Funny)
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 .lwaje .og8unl98nst.oby487rw;zbv5l936tlisd rnzsche.ldnj ekqb;wv4ioa
eo84yre kl76v5los79y6to89xep89x7e4v6eotyl9e84lbvr8xy76ebl9txevl9r8
ygnl8odvr,i8xeyvti8seybvto eby5tli8xevynlr8n776vsot7vnl9xe84nyu
aowpibtulieut,iwvy,o39u dryswrl9uzfna484ytlo8cwjnlv ig78wfp9cnusgl8w
3n4aly8u
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... (Score:5, Funny)
What?!
How dare you sir! My mother is a saint!
Re: (Score:3, Funny)
y to9y347icr yisuryctw 37bt6l9s38 ucr,ugbvt6o8w 3nyu.oulv87vg
Ia! Ia! Cthulhu ftagn!!
how is this different from a smart card? (Score:2)
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 ...
Re: (Score:2)
In this case you have to trust whoever writes the P2P software that it actually erases key packets and doesn't just forward them all to the author for, uh, future reference.
Hey hey! (Score:2)
Sounds like we would simply need the device listed in paragraph 3, sentence 5 here [wikipedia.org] :-)
in order to decrypt it
50% Tech, 50% Hope (Score:4, Informative)
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. (Score:5, Informative)
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: (Score:2)
So, in order to attack it, all you do is run a Vuze index server and store all of the key/value pairs that look like keys instead of a block hash. Ready made dictionary attack.
Legal Problem (Score:4, Interesting)
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.
Re: (Score:2)
Would that be different than if someone decided to use normal cryptography, and encrypt their emails to another party unbeknownst to the same company?
In both cases, the company would not be able to provide the cryptographic key to decipher the messages.
I'm getting the impression mos
The Best Forensics (Score:2)
Good Morning, Mister Phelps (Score:2)
Eight hours? The IMF usually needs 10 seconds/
Obsolete technology (Score:2)
..by Kindle.
What happens to the gibberish? (Score:2)
I hope they thought about what to do with the content after the key is gone. Sounds like it stays out there, permanently scrambled, local storage and perhaps distributed.
If this becomes popular, then even though some people will delete messages, others will just let them gather, on servers, on their own machines, on forums and web pages...
I imagine after a few years, half the digital storage in the world could be useless data. :)
It is a clever hack, but not tidy.
Hmmm (Score:2)
You know, I never understood why short e-mail message have to be "transmitted" to the recipient in SMTP. As such, my e-mail is available for e-discovery requests aimed at the recipient as it's on the recipients computer.
In cases I didn't want that, I stuck an image on my web server and did a link to the https://passwordserver.com/dir1234/abc.jpg [passwordserver.com] with headers set to no-cache. This being a CGI program.
The result is pretty similar TFA, but much easier obtained. P2P isn't going to be opened up on our netw
Re: (Score:2)
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: (Score:2)
Are you blind? It's not free but definitely open source.
Re: (Score:2)
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: (Score:2)
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 licen
Re: (Score:2)