This Email Will Self Destruct...

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

Comments

A trusted third party won't help.

[mkb]

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?

A frank discussion of why this seems unbelievable

[Jherico]

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

Re:Done before

[Dan Kegel]

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.

Re:I wouldn't trust it.

[Tau Zero]

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

I wonder who they're targeting

[Mignon]

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.

Re:"...given enough compute power"

[radish]

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

Re:How it works?

[QuMa]

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.

Quantum computing just means doubled keysizes.

[Paul Crowley]

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

Done before

[jd]

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.

Re:Done before

[Dean Brettle]

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.

I wouldn't trust it.

[Accipiter]

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?

How this works?

[bjk4]

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.

[sparks]

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?

Re:I don't get it.

[ucblockhead]

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.

Re:I don't get it.

[jonathanclark]

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

Re:I don't get it.

[cpt kangarooski]

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 ;)

This could provide legal "deniability"

[jjo]

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

Other serious problems with this idea

[neophase]

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

A little info...

[rlm]

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

[dattaway]

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.

Re:So what?

[ucblockhead]

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

Re:Nice idea...

[um... Lucas]

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.

Maybe okay?

[mOdQuArK!]

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

"...given enough compute power"

[Paul Crowley]

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