Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Encryption

'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."
This discussion has been archived. No new comments can be posted.

'Vanish' Makes Sensitive Data Self-Destruct

Comments Filter:
  • Re:Copypaste (Score:5, Informative)

    by Anonymous Coward on Tuesday July 21, 2009 @12:24PM (#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.

  • by MeanMF ( 631837 ) * on Tuesday July 21, 2009 @12:30PM (#28771255) Homepage
    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:Copypaste (Score:1, Informative)

    by Anonymous Coward on Tuesday July 21, 2009 @12:40PM (#28771389)
    And yet you obviously didn't RTFA.
  • by vertinox ( 846076 ) on Tuesday July 21, 2009 @01:05PM (#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.

  • 50% Tech, 50% Hope (Score:4, Informative)

    by Anonymous Coward on Tuesday July 21, 2009 @01:19PM (#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.

  • by Animats ( 122034 ) on Tuesday July 21, 2009 @01:21PM (#28771993) Homepage

    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.

Make sure your code does nothing gracefully.

Working...