'Vanish' Makes Sensitive Data Self-Destruct

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."

Comments

Copypaste

[sopssa]

'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

[binaryspiral]

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

[Anonymous Coward]

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

[QX-Mat]

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

[NotQuiteReal]

heh - the Print Screen button is a terrorist tool!

Re:Copypaste

[CannonballHead]

You should suggest it to gmail. After all, they already have a way to change the timestamp of the e-mail 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

[sparkchaser]

I just spent the last 5 minutes trying to activate that feature. Well played, CannonballHead, well played.

Let's not kid ourselves

[Bruce Perens]

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

[Eevee]

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.

Re:Let's not kid ourselves

[MeanMF]

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.

Re:Let's not kid ourselves

[mlts]

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

[EdZ]

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

[dmdavis]

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!

Obvious application

[Dice]

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

[Eevee]

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

[bluefoxlucid]

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

Oh yeah. I had the balls to ask.

So that's what's been happening

[hwyhobo]

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".

Adaptability

[arizwebfoot]

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

[drxenos]

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

Re:Adaptability

[element-o.p.]

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:We already have better tools for that

[Eskarel]

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.

Not useful for DRM

[swillden]

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

[Bruce Perens]

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?

[wjousts]

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?

[mcgrew]

OMFG, my ex-wife is posting at slashdot!

Corporate crimes

[wjousts]

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

[westlake]

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++

[Mysund]

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

At last...

[quarkoid]

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...

[vertinox]

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

What?!

How dare you sir! My mother is a saint!

Re:At last...

[A. B3ttik]

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

Ia! Ia! Cthulhu ftagn!!

Re:Privacy Assurance == DRM

[vertinox]

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.

50% Tech, 50% Hope

[Anonymous Coward]

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.

[Animats]

First, as is typical, the Slashdot article is three steps removed from the actual paper, 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, incidentally.

Legal Problem

[Phrogman]

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.