Slashdot Mirror
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.
"
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.
What if there was a key server that provided a second key required to decrypt the message (i.e. you'd have the first)? After the expiry, the server would no longer provide the key, and would delete it. That would get around the turn-back-the-clock thing.
And because BOTH keys would be required to decrypt the message, someone couldn't use the copy on the server to get the message, unless they could persuade you to divulge yours.
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?
...or otherwise take a copy of it. Hmmm...
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 am not a number! I am a man! And don't you
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.
So, this means that my printed hard copies will self detruct? Arghhh, I would put them som where else so my important documents don't go away with them....
The reason both parties will agree to the message
self-destruction is that in the market D.Inc. is
selling to, both parties -want- the message to
self-destruct.
There's this enormous problem where when one
company sues another, they demand, and then -get-,
enormous chunks of backedup email archives.
Have a look at jwz's rant about MS demanding
the collected archives of really-bad-attitude,
for example.
D.Inc provides a means for a company to plausibly
claim that the mail archives are simply not
available. For some businesses, this is an
extremely valuable claim.
They don't address, and are not trying to address,
any issues you and I might have with sending mail
to each other.
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?
I am not a number! I am a man! And don't you
1) Place a key word in the subject so that your message can be found. You know, like NARF.
2) Begin your post with a few cuss words and a statement of how superior Windows 2000 is to Linux. This will get your post moderated down to -1 so that most people won't even see it.
3) Use previously aggreed upon phrases to convey your message.
There, even if the DOJ manages to find a nine month old archive of SlashDot the message will have been posted by an Anonymous Coward with no way of knowing who was reading it.
Now to figgure out a way to pattent this...
Oh, and before I forget. Romeo Tango: "The Monkey is rubbing the Dolphin with cheese." And this time I _MEAN_ it!
1. Bill (or Mallory) decompiles Disappearing STO client & figures out the protocol.
2. Bill lays down phat codez & makes his own client that pipes K wherever he wants
or
1. Bill hits printscreen.
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
It doesn't mean much now, it's built for the future.
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
Jherico
What can the average user can do to ensure his security? "Nothing, you're screwed"
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.
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...
That is, in fact, the plan.
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. :-)
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.
https should address that.
If you describe the other attack methods, I'll try to address those too.
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.If their business plan centers on the scheduled destruction of session keys, and a particular session key has not yet been subpoenaed, they have every right to go on doing what they promised.
Even keys for information that doesn't relate to any current investigations? Do they also require you to keep all your paper records forever, just in case?
With the Blair government talking about handing out 2 year prison sentences to people who refuse to hand over their keys on demand it sounds like a handy thing to have. A one time only decript key would be even better though. I can't understand how it would guard against something as trivial as changing the clock. Anybody got any ideas?
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...
Still, a system that relies on "both sender and receiver wanting the message to dissapear" seems pretty limited...
Your Servant, B. Baggins
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.
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
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
--
Deja Moo: The feeling that
Time is Nature's way of keeping everything from happening at once... the bitch.
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.
See the previous (huge) discussion on
---- Den ene knappen er powerknapp, den andre er Bender voice knapp "Bite My Shiny Metal Ass"
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.
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.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Man, isn't that Windows 2000 a great operating system? Once it comes out in a couple of days here, Linux will disappear from the face of the planet! Anonymous Coward at the temple of the moon. Did you get the stuff? Be there at 9 am. Fnord!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
So people should start running programs they get in their email? This has caused enough problems already (ie. Melissa virus, BackOrifice, Happy99, ...). If people start executing programs they receive, someone can just send them a program like BackOrifice that takes screen captures of their "disappearing" mail and posts them on the internet. (There is no such thing as a "non copy-able" format.)
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.
--
Xenu loves you!
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
neophase is correct -- disappearing inc (aka "reappearing inc") is producing at this time highly irresponsible marketing:
-- the only thing worse than a lack of security is a false sense of security, particularly with email and privacy issues. more often than not email sent via a disappearing inc method will be reappearing ink.
-- they are not "shredding" anything; be suspicious of companies involved in security who are not precise
-- why not subpoena the reappearing inc server? (how "shredded" are the keys?)
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.
 : 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
--
-=DaveHowe=-
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
- Damnit, I'm dead Jim
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?
My comment was too long. Thus I made a page out of it.
".. I like pork!"
- Brak
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 ]-
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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!
--
This is a lawsuit (actually countersuit) claiming that I libeled them. The website contains the information about the lawsuit.
Why don't you decide for youself?
Injured worker wins against Mattel!
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?
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
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?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
So one just hopes that your favorite emailreader/unencrypt software doesn't use some /tmp file for storing the plaintextmessage.
but would microsoft exchange still crash? i'd like to see an invention that makes Exchange worth using...
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 --
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
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 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 British government wants key recovery laws such that you are required to provide the keys to encrypted data ... if you haven't got the keys, that's your problem, not theirs...
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...
I am not a number! I am a man! And don't you
Sounds like they have a session key, and are trashing the key after the time period expires. Hope their encryption is good.
...phil
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
..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.
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.
--
E2 IN2 IE?
The message, M, is created by the sender. He also creates as key, K, say a random string of bits the same size as M.
Sender sends M~ = M xor K to recipient. Sender sends K to Disappearing.
To read the message, the recipient retrieves K and calculates M = M~ xor K. Hopefully, the plugin that handles this also makes it hard to accidentally store a copy of M in plaintext.
At expiration time, Disappearing deletes any trace of K. If the sender did so too, no-one can read the message any more.
Any other encryption technique could be used with this, but xor is perfectly fine (since it is used only once). The downside is the key size.
Your random number generator had better be good.
-----BEGIN PGP SIGNED MESSAGE-----
N IoOxdbcSSqkAmwUj
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/4mCelLHfp8d083EQK0vQCfebzQjvZtxB2WGB3
aO2Li0a1IncBjJZEe/L3bU8H
=pXcN
-----END PGP SIGNATURE-----
After you have read this sentence, this posting will self-destruct in 10 seconds...
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.
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
- 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
==================================
neophase
Queue, not 'cue.'
- 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
So, when I read my Mail via Pine or Mail it will still self-destruct?? HAHAHAHAHA. Wonder if I get a custom copy of Pine or Mail too?
...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. :)
It's all about cheese whiz and devil worship - Overheard in bar one night. >:)
Be cool to watch hardcopies erase themselves.
I'd get to reuse the paper over and over.
Save a tree!
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
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.
-- Ryan
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 use encryption so that every mail relay the message travels through does not copy off a plaintext version of your mail. If I was the FBI and wanted to trace email from an AOL user, I would just have AOL keep a copy of every incomming and outgoing message sent through one of their mail relays. Let us not also forget every hop and router these messages travels through. Hell, just slap a packet sniffer with a huge hard drive and, well, you get the point.
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
6th Street Radio @ddombrowsky
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.
--
until the amazing Disappearing Business Plan gets a subpoena to generate a specified key, with threats of contempt of court, harboring known criminal & assistance of crime if they don't.
Why should this company be trusted trent?
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]
The cake is a pie
No it isn't. It has been thought of countless times before, & discarded for the same reasons we're seeing regurgitated here. there is NO WAY to make this work.
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.
Time flies like an arrow, Fruit Flies like bananas.
Hmmm...sounds like a screen capture with gimp could break the code....hehe
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.
it's sad when a company thinks they can make $$ by a shaky concept and a cute name (disappearing inc -- get it?). however, investors seem to go for anything with the term "high tech startup" prepended to the name.
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...)
Maybe I don't know enough about this, but isn't there a few security holes that are waiting to be exploited?
First off, if a hacker wanted to blow the email up prematurely (sp), all [s]he would have to do is screw around with the time. Not as hard as one might think.
Second, how is the bomb set off? Does the email contain some type of program to do it (trojan/virus alert) or would you need a special client?
Like I said, I don't know too much about this. IMHO, if you don't want someone to get to the email, don't send it!
tyler
trevlix@yahoo.com
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....
Insert mind here.
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.
--
Xenu loves you!
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