Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Encryption Security

This Email Will Self Destruct... 112

Posted by CmdrTaco from the read-it-before-its-to-la dept.
Buggernut writes "A startup high-tech firm called Disappearing Inc. has created a system that does just that. It encrypts each e-mail message, lets the sender set the key's life span at anywhere from a few seconds to years, then turns the message back to gibberish once the key self-destructs. "
This discussion has been archived. No new comments can be posted.

This Email Will Self Destruct... More

This Email Will Self Destruct...

Comments Filter:

  • Dangerous, stupid idea (sorry) (Score:1)

    by Anonymous Coward
    A lot of people have already said enough about the "deletion" of mails and how clueless the idea is. The more dangerous thing is that the whole process advocates "Security by obscurity" by deleting a key and thus claiming it to be magically removed from reality. What a rubbish! Any semi-skilled cracker/hacker/programmer can trace the packets, save the memory state etc. from a machine and so save the key forever. And mind you: Centralized storage of keys is exactly what the intelligence services like. It's the wrong signal for customers and a proof that this firm does NOT understand cryptography AT LARGE. Sorry, next please.
  • A trusted third party won't help. You still need the cooperation of the software on the receiver's computer. The receiver could modify the software such that it does not cooperate.

    Thus it requires a certain amount of trust in the receiving party that nothing has been tampered with. If you trust the recipient so much, why not just ask him/her to delete the message? If you trust the person so little, why are you sending the message in the first place?

  • In PGP the time stamp is encoded in the key and it compares against the system clock to see if the key should be used. Obviously this will stop no one -- I am not exactly sure what the point of the exercise is in the first place.
  • I was kind-a looking forward to a BOOM, not some stupid deletion of a key thing... ;)
  • It would be more useful to have selfdestructive floppy disks. Something like in that TV series "Mission Impossible". I'd like to put my backups to that kind of media ;)

  • By the way, all you would have to do is have a hacked client and it would make the whole thing useless.
  • The point is that the encrypted form can be cached anywhere along the route -- at routers, firewalls, etc. The underlying deniability comes from the encryption. Care to disclose what is being used? Also, how is the key transferred to my mail client? SSL? How do I know disappearing will destroy the key correctly?
  • to kill more trees.

    There's no saying that you can't print out copies/screen grabs when you read it.
    So: Buy a lot of paper, and a fire-proof safe.

    P
  • Both GnuPG and PGP allow you to specify an expiration for a key. All that they're doing is setting that for you. Therefore the key need not be deleted, it just will not work after the exp date.
  • I don't believe that this system will work. There might be some neat gimmicks built into it to make it seem to work, but ultimately the idea is flawed.
    Consider, the article says that it works with (interpreted by me as "can be read by") any existing mail system. In my mind this narrows down how it will work to a few possible methods. The first is that the information is stored on a central site that is gated and all the e-mail contains is a link into the site with cryptographically secure information on what message is being linked to. Then the site could ensure that no mail was displayed past a given date.
    The second method would involve sending an executable of some sort as the message with the date and time information in it. The executable, presumably java for cross platform support, would decrypt the message when appropriate and the first time the message was opened (read "executed") after the deadline date, the key to decrpyt would be erased.
    Both of these approaches have a problem in common. If at any point the message is to be used for its intended purpose, i.e. rendered to the screen for a person to read, then it will have to be done so in decrypted form and can be captured (almost laughably easily) in said form. This however requires planning on the part of the capturer and might require him or her to know that the message will not be available in the future. Depending on how seamless the interface is, you might not know that you're looking at a message that won't be available in 2 weeks. Certainly it will be in the selling companies best interest to make such a feature invisible to the recipients so that they will have no reason to capture to the message to a trusted data store.
    The second approach, that of an executable, has additional problems. An executable that isn't being run is just a piece of data. Again, this really only becomes valid if you know your message will self destruct, but if you're concerned a message will hari kari next time you open it as an executable that automatically executes might, then don't open it. Disect the executable. No matter how clever the coding is, if this product does not rely on any outside agency for decryption as it does in the example above, then all the information required to decrypt the message MUST be in the message itself. Its only security is the secrecy of the algorithm and that's no real security at all.
    Note that I am avoiding the entire topic of validating dates. Its absurd to think that you could simply set your clock back to defeat any mechanism that is supposed to be secure over time, particularly when that product is an e-mail system. I would assume that the product probably queries publicly available time server so that local time authority is ignored. At any rate, the products efforts to validate the current date and time and the hacker's efforts to spoof a date and time becomes and arms race unto its own.

    Jherico
  • Hm? 'Doze isn't the only operating system that uses swap... Linux uses swap, Solaris uses swap, *BSD uses swap... what DOSEN'T use swap?

    BTW, on Unix (I don't know about windows) a program running as root can request that it not be swapped out. GnuPG does this for security purposes.
  • That's right. The Disappearing Inc. stuff is simply an aid for groups that want to arrange for internal email to go away after, say, a year. There are many ways around it; its value lies in the fact that groups using it have a common interest in having the mail go away after a while.

  • The Disappearing Inc. software is for people who share a common interest in having email go away after a while. It doesn't keep people from making plaintext copies, but it will probably remind people that making plaintext copies goes against their common interest.
  • I designed the Disappearing, Inc. key server protocol and wrote the first implementation of it.

    I don't think it's a marketing gimmick. It's a genuine effort to minimize the number of copies (on disk, in RAM, on the network) of decrypted email messages and the keys used to decrypt them; in principle, most of the time there's only one copy of the key, and if you delete that one copy, the message is unreadable. There are many ways people could subvert the system, just as there are many ways to spread secrets using the phone or paper. The point of this system is that you have to *try* to subvert it to cause plaintext copies to proliferate, as opposed to normal email, where they proliferate by default.

    Nothing is perfect, but the Disappearing Inc. stuff probably doesn't suffer from the problems you suspect.

  • I understand your skepticism. I was skeptical too. I'll try to address your points. Please let me know if I you think I've missed something...

    I do hope you encrypt the mail reading session with a separate key - otherwise the clear text is going over the network between DI and the receipient.

    That is, in fact, the plan.

    And you need to hope that the receipient will not hit the "Save as" button on his or her web browser ("for convenience").

    Yes. The sender must trust the recipient to not subvert the system before the key is deleted. This level of trust is implicit in any system of this kind. We can't prevent someone from taking a picture of their computer screen either. :-)

    Then there is browser caches,

    HTML forms are not generally cached to disk. A more likely leak along these lines is swap files. I discussed those in my original message.

    Web proxies

    https should address that.

    and so on - there are more ways to attack this than I can count on my fingers (in binary).

    If you describe the other attack methods, I'll try to address those too.

    The whole concept sounds like nonsense to me - if you trust the receipient at all, you can just have him delete the email after being done with it.
    I can think of a lot of recipients that I would trust to not intentionally reveal a private conversation, but that I definitely would not trust to be competent enough to completely delete a message after being done with it. Just about anybody non-technical falls into that category. "Yeah, I deleted it. I clicked that X button. Whaddaya mean that isn't enough? I can't see it anymore..." You get the idea.
  • I loved the cartoon with Inspector Gadget. But here in the USA it is not shown at least as I am aware of it. I wonder whether they will use Gadget as a marketing vehicle? Matyas
  • Or, more importantly, since this will probalby be (at least) a Windoze based product, it will probalby be in swap, anyway...
  • It's not exactly clear from the rather sketchy article, but if the key comes from a service (i.e., special application opens message X and sends request to server http://foo.bar for key), then the server could destroy its copy of the key, say... 24 hours after the first read request.

    Still, a system that relies on "both sender and receiver wanting the message to dissapear" seems pretty limited...

  • It doesn't necesarily matter if you can change the date. If the time is set to five minutes, and five minutes after reading it the key is erased, changing the date isn't going to help. You've got to make sure the key isn't recovered off the disk somehow, though.
  • Aw, who am I kidding? I love raining on parades.

    Once the e-mail is in plaintext format, the simple majesty of Print Scrn will allow you to save it in some format. You can't just copy and paste it into Notepad... and if these are too low-tech for whatever system they're using, well, there's no way to prevent someone from writing a program that simply drags the contents from RAM! Good grief, where do people come up with these ideas?

    --- Dirtside

  • displays the SHORT message in a NON COPY-ABLE/PASTE-ABLE FORMAT
    And this protects against screen-buffer readers and Polaroid cameras how?
    --
    Deja Moo: The feeling that
  • The product made by the company where I work has a messaging component. Most, if not all, of our clients get shipped backup tapes of the messages sent and received by their employees. I believe most of our customers are required by the SEC to keep records of this communication. This means that the entire financial industry couldn't use this system.

    Regulating agencies aside, I think most companies are more interested in monitoring their employees than they are worried about future lawsuits.

    Incidentally, our product address the issue of saying something you'll regret later by having a filter in the program that prevents you from using words like "shit" and "fuck". ("s h i t" and "$hit" go through just fine, though.)

    I also wonder how this system would work in England, which IIRC was proposing to make witholding encryption keys a crime.

  • Argh! I meant you CAN paste it into Notepad. Stupid keyboard.

    --- Dirtside

  • See the previous (huge) discussion on /. about quantum computing and the (future) possibilities it offers. All the "every particle in the known universe..." arguments used to claim cryptographic strength are based on our current understanding of computation and calculation. Throw that out and anything is possible....
  • At the same time, it must be noted than any encrypted message is breakable by brute force, given enough resources.

    You make an excellent point about key lifetimes, but the statement above is not correct.

    If you want to know why, read Chapter 7 of Bruce Schneier's Applied Cryptography. The chapter is fairly short, and you could even read it in the bookstore if you don't want to buy the book. (Though I do recommend the rest of the book as well.)

    The short version of the chapter is that beyond a certain key size, there simply is not enough time, matter and energy available to complete a brute-force attack before the sun swallows up the earth. Once the key is big enough, a break depends on finding a weakness in the algorithm itself or compromising the key in some other way. Other ways could include: physical theft, cameras, bribery, keystroke monitors etc.

  • There are a few ways I can see to do stuff like this, the simplest being to embed a java crapplet in the mail.

    That's fine except that there's no way I'd EVER let my mail software run java. Have you any idea how much risk you'd be opening up there?

    Another possiblity would be to have the mail readible only by a mail program enabled for this sort of thing. Well that just locks me into a proprietary mail client and it doesn't prevent screenshots (Probably not cut and paste either.) Already being stuck with a proprietary mail client (Bloated Goats) I can tell you, it really sucks and if it doesn't support your OS, well, you're just out of luck aren't you?

    If you really don't want your E-mail read by an outside force, encryption is still the way to go. Especially if your encryption program supports the chafing/winnowing capabilities suggested here -- run the message through the key on your hard drive and you get "Steve: How's the wife? Be sure to order some pizzas for all the employees on friday. -Bill" but run it through the one on the floppy in the secret compartment on your desk and you'd get "Steve: Spread some FUD on Linux, would you? And I want to buy some more stock, so bad mouth our stock prices so I can get a better price on it. -Bill" You'd get the same advantages but fewer of the disadvantages.

  • It's meant so that someone wanting to send you a message, pulls out your public key and it screams: EXPIRED! at them... That way, they'll go ask you for your new (possibly bigger/different algorithm) key.
  • Even if quantum computing is possible (which I don't think it is), Grover's algorithm just means that the resources needed to brute-force a key grow with the square root of the size of the key space. So 512-bit keys should protect you if you're worried about the entire universe being turned into a quantum computer.
    --
  • Hope this isn't seen as flaming, just wondering if this person thought this out.

    Executable Code

    In every email, running all the time so it can see the clock ticks, and without your knowledge or permission. And even then, you're trusting the client to not be hacked, and to launch the executable code contained in the emails. The only way I could maybe see around that last point is if each message is different enough that you must execute it for it to decrypt itself. Even then, it probably wouldn't be able to tell if it's in a sandbox, and you simply limit time in the sandbox. Basically, I don't see any way it's feasable without assuming WAY too much about the client machine. Including binary architecture and OS.

    As a side note : When will they finish Mozilla??! Netscape sucks and IE is driving me up the wall!

    "Binaries may die but source code lives forever"
    -- Unknown

    SkyHawk
    Andrew Fremantle
  • Of course, one time pads aren't even breakable by brute force. The only hope if something is encrypted by OTP is that the random numbers are flawed.
  • If I am reading this correctly, you have to go request a key for message X from a server (presumably the sender's, unless HE has to request the key in the first place from the company)
    I don't know about the rest of the Slashdotters, but I don't spend all that much time actually connected to the internet - I am much more likely to link, download email and news, then unlink and have phone line available (and not running up my phone bill, which is per-minute in the UK) while I read offline. To have to connect to the Net *again* if I wish to read my inbound mail would be discouraging, to say the least.
    &nbsp: Odds would be very high someone would "hack" a version of their reader to get all the keys as the mail comes in, and store them for later use (possibly ignoring expiry data) simply to keep from having to reconnect once per message
    --
  • >>>> So 512-bit keys should protect you if you're worried about the entire universe being turned into a quantum computer.

    Quantum computer is a massive parallel machine which does infinite number of computation in one operation (Wow! It this mean that famous Infinite Monkey theory has come to reality?). So how much the length of the key, it won't protect anything - at least, that's what I heard about quantum computer.

    But since it seems that we'll have access to quantum-encrypted communication device (which already exists) before era of quantum computer arrives, I guess there's not much to worry about it.

    By the way, does anyone know about DNA computing?
    It seems it could be a threat to today's encryption before quantum computer arrives.
  • Disclaimer: I write code for Disappearing Inc.

    Disappearing Inc. will certainly educate its customers; the system only helps its users implement retention policies, it can't enforce them. The education will start before customers start using the Disappearing Inc. service, so I don't think DI will be engendering a false sense of security.

    You ask "How shredded are the keys". We are trying to reduce the number of copies of the keys and decrypted messages made during the course of normal operation. Most of the time, there will be only one copy of the key, in one file on a RAID filesystem. When the key is erased, we will write over the region of disk where it is stored. At some point, we'll probably audit our software and sniff the entire physical disks for traces of old keys, just to make sure none are escaping deletion.

    So they should be fairly well shredded.
  • Ok, I havn't read the article, but, from the replies, I get the feeling that the message is sent to a server where it is decrypted and then returned to the client...

    Doesn;t this completely defeat the object of encrypting emails? I mean, it's being sent between the server and the client in plaintext, (same with key), so anyone with a packet sniffer can get the key and the email when the email is recieved and read.

    This is gonna fail, big time
  • Disclaimer: I write code for Disappearing Inc., but I'm not an official spokesman.

    Aaron, you're on the right track. The tricky part is making this work conveniently, so that users don't absolutely have to have a separate email client to read or write this kind of email.
  • If it's so easy to scan the last 10 or so writes, why isn't my 8 gig hard drive more like 80 gigs?
  • ..and if you misread the message, go off to Africa, get yourself in some serious trouble, you better hope you have a dog like Brain to bail you out. Does the message have a flag for blowing up in the chief's face as soon as you're through reading it? :)

  • I guess if you want to avoid getting sued or being able to prove that x-person sent it then it would be fine, but couldn't I just set my systems clock back?

    And even then, can't I just cut and paste the message to another file if I want to save it? Perhaps it's semi-useful for encrypting messages between two parties and keeping other people from reading it, but... bleh, it just seems fishy. I honestly don't understand why, if that was the case, the reciever couldn't just use the DELETE key on his keyboard.


    -[ World domination - rains.net ]-

  • Done before (Score:4)

    by jd ( 1658 ) <imipakNO@SPAMyahoo.com> on Friday October 08, 1999 @06:12AM (#1629378) Homepage Journal
    There are several companies offering this. The idea seems to be "Don't be like Bill Gates", and leave incriminating e-mails around.

    IMHO, it won't work, as people will either be forced to use a specific e-mail product, or there will be a high risk of the self-destruct system not working.

    Even if the message DOES self-destruct, so what? You can scan a hard-disk and read off the last 10 or so layers of data, which might include the non-encrypted form, or the encrypted form with a valid key. From there, it'd be child's play to get the message.

    Yes, you can use wiping software, which will write over the sectors of a deleted file N times, to ensure no data could possibly be read from them, but even there, there are problems - temporary directories, swap space, etc, which might not be wipable.

    There are far, far better ways to secure e-mail from prying eyes. This is a marketing gimic, for those too paranoid to trust their systems, but not knowledgable enough to know what can be trusted.

  • I wouldn't call it "self-destruct", since the message still exists, but in an encrypted form. You can't rely on this for absolute safety because with enough computing power, any message could eventually be broken.

    On the other hand, for most uses, this would be more than enough protection for the people involved. I also like the fact that it promotes the idea of sending more email as encrypted documents. Keep making encryption more mainstream!


    --

  • As the article says, having an email "self-destruct" is not much good if someone has a plaintext copy of it - I would have thought the applications for this technique would be fairly limited.

    Also, if the message is "timed" to self-destruct at a particular time, could you "turn back the clock" on it?
  • It's a good idea, but poorly implememted in my opinion. I wouldn't trust this system, mainly because it relies on too many factors.

    The encryption system has a time limit. That means the other person MUST agree for it to work. Wow, great plan. "Mr. Phelps, this tape will self destruct in 5 seconds, but only if YOU think it's okay." That blows a hole in the entire privacy deal. Anything you encrypt obviously wouldn't be for anyone else's eyes, right? What's to stop the recipient from making a copy of it? His or her promise?

    It would be better if the message was converted into an encrypted executable file of some sort, and sent as a small attachment. Once the recipient gets it, they run the program. It decrypts itself, displays the SHORT message in a NON COPY-ABLE/PASTE-ABLE FORMAT with a sender setable countdown. Once the countdown reaches zero, the app closes, re-encrypts itself with a totally seperate INTERNAL key, then destroys itself.

    Of course, there's problems with this way too, but the point is, there is NO SUCH THING as 100% secure communications. Period. So you're going to trust your sensitive messages to E-Mail?

    -- Give him Head? Be a Beacon?

  • So one just hopes that your favorite emailreader/unencrypt software doesn't use some /tmp file for storing the plaintextmessage.
  • What's to stop the recipient -- or a third party who subpoenas the time-expired mail -- from simply setting their clock back?

    Either this relies on security through proprietary software ("only our ACME special- purpose self-deleting email reader can decrypt this message!") or there would appear to be a flaw in it as wide as a --

  • How this works? (Score:3)

    by bjk4 ( 885 ) on Friday October 08, 1999 @06:14AM (#1629386) Homepage
    I would be interested in hearing how they intend to get pine(1) to delete the key to these encrypted messages. Here is what I could think of for their (probably proprietary) system:

    1) Use Javascript for people using Outlook. Scripts could encrypt and decrypt messages on the fly, erasing the key from the message after x days.

    2) Use central server (ex: over a webpage) to delete the key from the server after some time.

    3) Use a proprietary email format that requires it to be opened using their executable which manages the keys.

    As someone else suggested, the entire security breaks down if someone saves a plaintext copy. Should their program not give you copy&paste, I would consider it crippleware. Assuming not, I ask what the point is for this scheme.

    I remember when www.terraserver.microsoft.com first came out, Microsoft used Java to prevent saving the images you saw. Of course, I just pulled out my trusty screen capture program and saved a copy of my hometown anyway... I guess this just shows how you can copy&paste things without permission from a program.

    So how do they plan to integrate this with existing environments? I don't think they can.

    -Ben

  • I don't get it. (Score:3)

    by sparks ( 7204 ) <acrawford@laetabil[ ]com ['is.' in gap]> on Friday October 08, 1999 @06:11AM (#1629387) Homepage
    It "only works if both sender and recipient want the message to vanish" as it says in the article. Having got the plaintext once, the recipient can obviously copy, print, or save whatever is there.

    So, given that both sender and recipient have to agree, why can't they just agree to delete the damn' thing?

    If there is a demand for this (and frankly I'm not convinced) surely it would make sense just to define a "Delete-After: " email header and work with that. Why involve encryption at all?

  • Surely if you want your email to disappear after a certain period of time you just make sure you store it on a Microsoft machine?

    (Admittedly you don't get that fine-grained control over when you'll lose your valuable data, but that's half the "fun"!)

    Tim.
  • If implemented properly, a system like this could be of considerable value in a corporate e-mail system. In the case of a lawsuit, ad-hoc corporate records (like e-mail) are, in general, a Bad Thing. The way a corporate lawyer explained it to me was:

    If the record is harmful to you, it can be used in evidence. If it helps you, it's inadmissable.

    (He went on to say that that's an oversimplification, but still largely true.)

    So, one would like to erase all e-mail after a certain time. Of course, the problem is that while most e-mail is ephemeral and would not be missed, some must be preserved. Any automatic deletion system would either delete important data (in which case the users would keep private copies), or fail to delete all that it should. Also, data backup systems try very hard to preserve data, and would likely defeat the mail-reaping systems unless carefully designed and maintained.

    I don't know how these people are implementing their system, but one way would be to require sender and recipient to have on-line access to a key server. It could work like this:

    sender requests a key of specified lifetime from server, which generates a new key,

    sender uses key to encrypt message, then discards key,

    receiver requests key from server, decrypts message, and discards key and decrypt when done,

    until the lifetime expires, receiver can repeat the above step as desired,

    finally, when the lifetime expires, server discards key.

    The vital benefit of this system is the ability to stand in front of the judge and say:

    "Sorry, your honor, but we have no way to recover those messages, and here's why."

  • The "deletion" of this can be no stronger than the underlying encryption since I can always keep a copy of it on the client side -- Disappearing Inc. never specifies what algorithm they use. This is just another web based email encryption service using a half understood knowledge of Public Key encryption to float an IPO. The only thing "revolutionary" about this is that they managed to get the Disappearing.com domain name. Disappearing by name, disappearing by nature...
  • From what I can tell by reading the description, the date on the user's PC isn't important - the key which is used to decrypt the messages is located on the servers at Disappearing Inc., and when the key "expires", it is erased from Disappearing Inc.'s servers.

    So, unless you know how to change the date on Disappearing Inc.'s servers (which they might notice after a while), it doesn't really matter what the date on _YOUR_ pc is.
  • I'd like to see how Disappearing Inc. gets to the tapes in my fireproof vault.

    Sounds like they have a session key, and are trashing the key after the time period expires. Hope their encryption is good.


    ...phil

  • ..and time-limited authenticated email.

    We could all then have virtual milk cartons complete with expiry dates... and trade them on E-bay.

    I can't think of any secure way of doing this without a central authority, but then, I'm not a mathematician.

  • If the technology even gets as far as a final product, I'm still wondering several things:
    1. Will this only work with X number of email clients among the Y number that exist, with Y > 2000?
      • If not, how many OSes would be supported via external viewer?
    2. Why bother with this when it will take very little time to either:
      • Crack the encryption?
      • Crack the viewer application?

    Why stop at encrypting and securing text messages? If 'expiration dates' could be put on files, old files that are no longer relevant/correct would have to be updated or deleted.

    If you are looking for anonymous, self-destructing messages, why not implement something in Java, and simply point to a URL, e.g.:
    http://www.mail.foo/cgi/destruct.cgi?1003383
    The applet would read the QUERY_STRING, decode the intended file, then let the server know when the file was opened and when it could be deleted. Additionally, this would allow the composer to dictate the number of times the file may be shown.

    Despite these ideas, nobody is going to be able to get past a screen capture. I'm not at all interested in the technology, and I don't think it will catch on in the rest of the world, either -- it's a fantastic idea, but I just don't see it being practical or secure.

  • -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    First- there is more information on their website
    (http://www.disappearing.com/) than there is in the Canoe article.

    After reading the vague description they give on their website of
    their system, I'm trying to come up with my own "self-destructing"
    cryptosystem. I'm only in high school, so I'm too naive to think of
    this as a potential business plan. And hell, this is the open source
    community, so at least I know you will put it to good use.

    Here goes - the Self-Destructing Cryptosystem (SDC)

    1. Alice and Bob both have a proprietary SDC email program.

    2. Alice logs into a trusted SDC server, owned and maintained by SDC
    Inc. Alice's client program encrypts the message with a random key
    sent from the server. Alice's client program does not cache the key,
    so it is forever lost on her machine.

    3. The encrypted message gets sent to Bob, and he uses his SDC
    client program to log into the SDC server. The server verifies his
    identity, and verifies his permissions for the random key. The SDC
    server then sends Bob the key to decrypt the message. Bob's client
    program also does not cache the key, so it is lost forever on his
    machine also.

    4. Alice sets they self-descruct time when she sends the message.
    When the time expires, they key is wiped from the SDC server.

    Ok, that's most of it. Here are a few notes/comments:
    Alice and Bob can have public keyrings to encrypt the transmission of
    the random key, so that eavesdroppers can't intercept the random key.
    This can be built into the program.
    Also, Alice could set the key to destruct N amount of time after she
    sends it, or N amount of time after Bob reads it.
    The only computer that needs to have the correct time is the SDC
    server, which would hopefully be trusted and secure. This is less
    vulnerable than relying on the time on the client computers.

    -----BEGIN PGP SIGNATURE-----
    Version: PGPfreeware 6.5.1 for non-commercial use

    iQA/AwUBN/4mCelLHfp8d083EQK0vQCfebzQjvZtxB2WGB3N IoOxdbcSSqkAmwUj
    aO2Li0a1IncBjJZEe/L3bU8H
    =pXcN
    -----END PGP SIGNATURE-----
  • That's exactly right. And since the key is kept on a keyserver, turning back the local clock won't let you read expired messages.

    I'm the guy who designed the Disappearing Inc. keyserving protocol and wrote the first couple implementations, by the way.

  • Disclosure: I work for Disappearing Inc.

    IMHO, it won't work, as people will either be forced to use a specific e-mail product, or there will be a high risk of the self-destruct system not working.

    Any recipient with a web browser can read the email. The ciphertext is stuffed in an HTML attachment and decrypted at the DI website if the recipient doesn't have a DI-enabled client. Since the key is maintained (and destroyed) on a central server, the (poorly named) self-destruct system is not dependent on the client.

    Even if the message DOES self-destruct, so what? You can scan a hard-disk and read off the last 10 or so layers of data, which might include the non-encrypted form, or the encrypted form with a valid key. From there, it'd be child's play to get the message.

    Only the ciphertext is stored to disk. Both the key and cleartext are held in memory. There is a small risk that the cleartext (not the key) could be swapped to disk while the message is being viewed in a browser, but the swap file would be overwritten more than 10 times in a relatively short period of time.

    There are far, far better ways to secure e-mail from prying eyes.
    I assume you are referring to PGP and/or S/MIME. IMO, the big advantage to DI's approach is that it allows for temporary trust. To send you a traditional secure email, I must trust you to never reveal it to a third party, either maliciously, accidentally, or under duress (e.g. court order). To send you a DI email, I only need to trust you to not reveal it until the key is deleted.
  • Yes, that key copy is erased but how do you know that I (the recipient) didnt copy the key when the D-I servers sent it to me?

    Also, if that is to prevent against the mail being used in a trial: The recipient might still be asked to tell from memory what the mail said. Unless you wipe the recipients memory or the r. himself too, but thats restricted to organizations higher up on the criminal scale than M$ I think. :)
  • It doesn't really matter, since there HAS to be a way to unencrypt it even if it is 'time-bombd' .. The only way they could truely blast it is by really deleting it; and I mean overwriting it with 0xFCFCFCFC (or whatever the government accepted way of shredding is).

    Let someone trust it, and then watch their horror as someone with a Linux cluster decrypts it and presents it Microsoft-Antitrust-Case Style ;-)
    --

  • The key to the whole scheme is that their server will only authenticate a message as valid for a limited time. You can save the plaintext if you want, but that doesn't proove anything -- it's just text, and for all I know you composed it yourself.

    The service they offer is that I send you mail (via their server) and then you can ask them whether I really wrote that text. They'll confirm that until the mail expires.

    Of course, if I'm stupid enough to sign it with asymetric encraption (c.f. www.theonion.com), then I'm shit out of luck. Unless I go and claim that my private key was compromised. And thereby open up all encrypted emails sent to me. Not a good way to make friends.

    Johan
  • My guess is that the key is stored in some proprietary server. That means that control of expiration is out of the hands of the client software. Unless it explicitly makes a copy, the information will disappear on the server's schedule.

    Paul Prescod


  • This "utility" does nothing but lend a false sense of security to the end-user, while generating money for the vendor. Here are some additional problems, which I haven't seen in the comments (yet):
    • The PrintScreen button. If you're trying to destroy all evidence that you e-mailed someone about The Bomb (TM), how can you guarantee that a printed copy doesn't exist? Others have mentioned the cut-and-paste-into-Notepad scenario, not to mention swap files, disk data recovery, etc. etc.
    • Key server availability issues. If you need to obtain the key over the net each time you access the message, you need to be on-line *AND* the key server must be up.
    • Sniffer-type attacks. What's to prevent me from recording all transactions by my co-worker, including the key retrievals? Is this key transmitted in cleartext? Is it "encrypted" by XORing it with some arbitrary word like "secret"?
    • General crypto cluefulness. Anyone who reads sci.crypt or coderpunks can expound upon the worthlessness of proprietary encryption algorithms.
    This proposed "system" looks like it's plagued with the same flaws as many other before it. It'll deceive only those too clueless to know better.


    ==================================
    neophase

  • The problem I see with it is that you have to trust the other party... which means they have to trust you. There's a lot of quite probably flawed trust going on.
    • You trust them to not take a screenshot or other capture of the "unsaveable" message.
    • They allow the message to be deleted because they trust your judgement that it's not a safe thing to keep around.
    • ... by extension, that means they trust YOU to have not kept a copy around, as a possible "get out of jail free" card.
    • ... wich they could have used themselves. "Look! I was acting under orders!"
    Other problems include actually deleting the message: impossible. Deleting the key: Impossible. In fact, I can open the message multiple times without even being a "hacker". Don't install their "plugin" on your machine. Send a copy to yourself at your home email address, then read the copy with their enabled-client. When you get home, do the same. If they use IP connectivity to log to a central server, they fail on two counts. A) their product is worthless in any kind of secure environment (firewalls) and B) I can just save the central server's response and patch that into the message.

    It's a gimmik (as has been pointed out before). Without control over the recipiant's recieving hardware, it's impossible to ensure that it actually happens.

    There's ways of doing it, of course. Some even require some decent skills to defeat... or a digital camera. Even Jim could have used that.

    --Dan

  • I do hope you encrypt the mail reading session with a separate key - otherwise the clear text is going over the network between DI and the receipient.

    And you need to hope that the receipient will not hit the "Save as" button on his or her web browser ("for convenience"). Then there is browser caches, Web proxies and so on - there are more ways to attack this than I can count on my fingers (in binary).

    The whole concept sounds like nonsense to me - if you trust the receipient at all, you can just have him delete the email after being done with it.

  • Gee, so you're saying no one should ever open an .exe attachment? If the attachment is from a trusted source, there shouldn't be a problem.

    By the way, anything that can't be right clicked on and choosing "COPY" is what I meant by non copy-able. Copy as in Copy/Paste.

    (You'll also notice at the end of my post, I freely admitted there were problems with my method as well.)

    -- Give him Head? Be a Beacon?

  • ...is that a copy of the email can be store elsewhere on a server, for backups, whatever. With this key, not only can you be sure that the person who gets it is the only one who can read it, but also that it won't be read later by somebody else. How many people turn back their CPU clocks before they open a file? *poof* Key disappeared, mail safe. :)
  • Be cool to watch hardcopies erase themselves.

    I'd get to reuse the paper over and over.

    Save a tree!

  • Re:I don't get it. (Score:3)

    by ucblockhead ( 63650 ) on Friday October 08, 1999 @06:26AM (#1629414) Homepage Journal
    I think that the idea is that it is encrypted on disk, to defeat programs that can resurrect deleted messages.

    Still, I can think of so many ways to defeat this that it isn't even funny. I know it may come as a shock to some of you, but I can actually change the date a computer thinks it is.

    (Please use that super-secret information wisely.)

    This will give newbies a great false sense of security, though.
  • Just don't think this is that exciting. I keep my emails around for a while, just so I can look up via archives. Why on earth would I want my email to disappear after a few days? The place I can see this having a big impact is places like M$ that always seem to be giving up their emails in lawsuits and such.


    -- Moondog
  • I agree, but if there is a change to SMTP headers to add the support you mentioned, how do you know the other end has the extension?

    Also data on disk can be recovered unless it is erased in a cryptographically secure manner. I know a certain person who had a laptop at a certain company, when he got fired for doing bad stuff he formatted the harddrive and gave it back. The company took it to a lab, recovered the data and sued his ass.

    I've gotten to where I will use the phone if I'm not comfortable having my words around forever.

    Mom's new mantra should be:
    "If you can't email anything nice, don't email anything at all."


  • A little info... (Score:3)

    by rlm ( 52965 ) <rmeans AT uclink4 DOT berkeley DOT edu> on Friday October 08, 1999 @06:36AM (#1629417)
    This is from their FAQ, just to answer a few questions:

    ------------------------------------------------ -

    2. How does Disappearing Inc. make email safe?

    Encryption: All email messages are encrypted before they are sent to make sure that they can not be intercepted and read.
    Authentication: To make sure to make sure that the sender and the recipient are really who they say they are, a user identification code and password may be required.

    Tracking: A complete audit trail is maintained for each message, indicating who has received the message and when they first read it.

    Retrieval: Using the email client of their choice and the plug-in from Disappearing Inc., users can decrypt and view any message that they are authorized to access.

    Deletion: Finally, at the end of the message lifecycle, Disappearing Inc. Universally Deletes(TM) the message from the local PC, the mail server, and backup tapes so that nobody can ever read it again.

    ------------------------------------------------ -

    So it looks like you can "use any email client you want" as long as it is one that they have a plugin for. I suppose if you use another, then you just can't read the mail. The last line about deletion sounds especially interesting, I assume that "deleting" means destroying the decryption key.

  • Groupwise does this (Score:3)

    by dattaway ( 3088 ) on Friday October 08, 1999 @06:37AM (#1629418) Homepage Journal
    Well, almost... Send an email to someone using Groupwise with the date in the headers set to a distant past. After the receiptient reads it, it will seem to vanish, only to be discovered the mail was sorted by date into the beginning of the cue (rather than when it was received.)

    I found this to be a neat trick and often place "this email will self destruct in 30 seconds" at the footer.
  • You've just discovered the market for un-real-time clocks for computers. Make the machine think that time is standing still, or that it's moving very slowly, and you could make a mint.

    Lacking the tech skills to capitalize on this, I will stick to my trade as a graphic designer, and make a mint the old fashioned way, with very delicate engraving ;)
  • I can just hear the salespeople now, "Well, in order to destroy the message you have to install this program called cron(8)..."

    Actually, wouldn't it be possible to have a time span somehow put into the encryption key? So that after a certain click of system clock the key would no longer decrypt the message. How to regular PGP keys "expire" anyway?

    -davek

  • You can take the fifth and refuse to say what you remember, though.

    You can also lie. If there is no contrary evidence, you can't be convicted of perjury. (Witness how a certain tycoon was able to explain what he didn't mean by "piss all over" without being brought up on charges.)
  • Spreading the message "encrypted == insecure" reduces the sum total of enlightenment in the world. Please don't do it.

    I wasn't trying to. I'm all in favor of more liberal use of encryption. I use encryption whenever feasable (the hard part is getting other people to realize why it's worth the hasle).

    At the same time, it must be noted than any encrypted message is breakable by brute force, given enough resources. With a strong enough key and current mathematical knowledge, this can be as good as unbreakable, but what about in 10 years? Do you still want your message secure then? How can you be certain that the advances in mathematics and/or computer technology won't make your security obsolete.

    In general, encryption is used to protect time-sensitive data. If the message is broken after X amount of time, it generally does the third party little to no good. The only way to prevent a message from ever being decrypted is to not have it laying around for anyone to get a hold of.

    Simply using encryption is not enough of a solution -- the limitations of encryption as a security measue, from both the social and technical standpoints, should be understood. If you haven't done so already, read the manuals that come along with PGP -- Zimmerman (and/or others) goes into great detail on what the limitations of encryption technology are.


    --

  • Slightly off the subject, but back in the old DOS days, I had some clock fun. I was doing a lot of TSR work, and it was fairly trivial to replace the timer interrupt. I wrote a little program called "warp" that incremented the clock by one or more extra every time the normal timer interrupt fired. Since most software (including DOS itself) normally doesn't look at the RTC, this had the effect of making the machine's time move faster than normal. I could accelerate the time to about a factor of nine before things started to blow up.

    Unfortunately, in these days of real OSes, it isn't so easy to do. (Though perhaps it would be fun to try under Win95.)

    Actually, now that I think of it, most windows users have rights to set their own date...

    [goes to check]

    Windows NT: The SetSystemTime function enables the SE_SYSTEMTIME_NAME privilege before changing the system time.

    [evil grin]
  • Well, once the spec is revealed or discovered, couldn't one simply write an app that downloads the message and the key, and simply ignores the expiration request?

    This would be useful on closed systems, where you're assured you know the set up of the client and know that they don't have the means to alter their setup, but if they can then it just isn't very useful, in my eyes.
  • From what I've heard, the reason this came about is some embarrasing internal e-mails from Microsoft that were sitting around on their Exchange servers that were later recovered for use in the hearings.

    I also heard that when the message "destructs" into gibberish that it would take half a million dollars and 10 years to recover it.
  • Hmmm...sounds like a screen capture with gimp could break the code....hehe

  • Security Threat, not Security Enhansement (Score:1)

    by Anonymous Coward

    This went around on BugTraq awhile back and was resoundly poo-poo'ed.

    The intent is to automaticly dispose of sensitive email which _BOTH_ parties agree to. The developers themselves in the article admit that clear-text messages can be pasted and saved.

    So the developers take your email, encrypt it and wrap an executable around it to provide for a temporary decryption.

    The problem is with that executable. Do _you_ automaticly run every executable which is emailed to you? Do you trace the full email headers to verify that the executable you expected actually came from the intended party?

    The more savy reader may recognize this as an open channel to spread viruses and trojans.

    The same effect -- two people exchange email and by mutual consent have it vanish without a trace -- can be readily achieved by:

    1) The sender sends via an anonymous mail server and GPG.

    2) The reciever deletes the email with one of those secure deletion programs which overwrites the disk sectors rather than just removing from the table of contents. Several are available. To make this complete, the reciever should use a separate account for the sensitive messages and a simple email client which doesn't cache. That way the inbox can be deleted after each message and every "ghost" copy exorsized.

  • Dunno if they really need to work hard to stop people from saving their own copies - since the scenario they're talking about is having copies left around which can be legally used as evidence against the recipient, I'm sure that the recipient (if intelligent) isn't going to go out of their way to defeat the security.

    I'm more interested in some of the other points.

    As I understand it, the message is encrypted in its saved form & is decrypted on-the-fly when the user wants to view it. The key is stored on the Disappearing Inc.'s servers, and is supposedly deleted when the message "expires". (I'll make a leap of faith & assume that they either scramble or don't store anything plaintext on non-volatile storage, even in the swap files).

    Is the whole reason for this just to make messages "expire"?

    It doesn't seem very useful to actually protect the messages from unauthorized viewing w/in the expiration window, other than the "normal" ways of authenticating who's using a PC (is there anyone who feels confident about these)? And you need to be able to connect to DInc.'s servers to retrieve keys.

    How strong is their encryption & authentication (for both the messages & the protocol with their servers)? Do they make these details publicly available so that people can audit them?

    For their stated application, it still sounds like it would be better to have a setup where everything is encrypted by default, and a defendent would either take the 5th or suffer a convenient "memory lapse" when someone is trying to force them to produce the documents.

    (Of course, if everything was encrypted for each individual, then companies wouldn't be able to read their e-mail - aaawwww...)
  • This idea is probably too far-fetched, but

    What if each email, encrypted as it was, also had an internal program that counted how long it had been in existence/decoded and that deleted itself after a set time? Then, the "clock" couldn't get "turned back," and you'd be safe, and free of another email in your inbox. Of course, this may be unrealistic, but I'm just wondering....
  • When "enough compute power" involves converting every atom in the solar system into a key tester and running the whole thing for a million years, I don't think it's a problem. I think 256-bit keys would be beyond even that.

    Spreading the message "encrypted == insecure" reduces the sum total of enlightenment in the world. Please don't do it.

    I agree that the system doesn't offer fantastic guarantees, but not for that reason.
    --
  • sweet... yet another mechanism for practical jokes, I'm looking forward to this one.
  • It is possible that making one thing more secure will make the rest of system less so.

    There must be some executable elements associated with the email in order for it to destroy itself.

    Instead of having the email destroy itself after certain time, it probably will be (if it can be) exploited to do other "stuffs". The effect will be like those we've seen in Inspector Gadgets - the message destroys itself and some of its surroundings ;)

Slashdot Top Deals

Technology is dominated by those who manage what they do not understand.

Close