3

As most of you know, email is very insecure. Even with a SSL-secured connection between the client and the server that sends an email, the message itself will be in plaintext while it hops around nodes across the Internet, leaving it vulnerable to eavesdropping.

Another consideration is the sender might not want the message to be readable - even by the intended recipient - after some time or after it's been read once. There are a number of reasons for this; for example, the message might contain sensitive information that can be requested through a subpoena.

A solution (the most common one, I believe) is to send the message to a trusted third party, and a link to the that message to the recipient, who then reads this message from the 3rd party. Or the sender can send an encrypted message (using symmetric encryption) to the recipient and send the key to the 3rd party.

Either way, there is a fundamental problem with this approach: if this 3rd party is compromised, all your efforts will be rendered useless. For a real example of an incident like this, refer to debacles involving Crypto AG colluding with the NSA

Another solution I've seen was Vanish, which encrypts the message, splits the key into pieces and "stores" the pieces in a DHT (namely the Vuze DHT). These values can be easily and somewhat reliably accessed by simply looking the hashes up (the hashes are sent with the message). After 8 hours, these values are lost, and even the intended recipient won't be able to read the message. With millions of nodes, there is no single point of failure. But this was also broken by mounting a Sybil attack on the DHT (refer to the Vanish webpage for more information).

So does anyone have ideas on how to accomplish this?

EDIT: I guess I didn't make myself clear. The main concern is not the recipient intentionally keeping the message (I know this one is impossible to control), but the message being available somewhere.

For example, in the Enron debacle, the courts subpoenaed them for all the email on their servers. Had the messages been encrypted and the keys lost forever, it would do them no good to have encrypted messages and no keys.

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
quantumSoup
  • 27,197
  • 9
  • 43
  • 57
  • 1
    What if while they can read it they just copy and paste the message? Or take a screenshot? Or use a digital camera to take a picture of their screen? – Christopher Tarquini Jun 30 '10 at 06:12
  • @chris-T I am not too worried about the recipient intentionally copying the message, but rather him/her having the diligence to delete it. – quantumSoup Jun 30 '10 at 06:16
  • This sounds a little like [off-the-record messaging](http://www.cypherpunks.ca/otr/). The messages are encrypted, and during the conversation, the recipient can verify the sender's identity, but later they can't. It's important to note that the recipient can store permanent copies of the messages and sender's identity. They just can't *prove* later who the sender was. – Matthew Flaschen Jun 30 '10 at 06:17
  • How about a "really, _really_ trusted fourth party"? ;) Your problem is that "trusted" parties can be compromised. That doesn't sound like anything close to a technological problem with a technological solution. – Paul Richter Jun 30 '10 at 06:24
  • @Paul Richter: Vanish managed to accomplish (partially) just that, by splitting the key up in pieces and storing them in anonymous nodes scattered around the world. These nodes also don't know they are storing pieces of keys; since it's built on an existing infrastructure (bittorrent DHT). – quantumSoup Jun 30 '10 at 06:27
  • "Had the messages been encrypted and the keys lost forever, it would do them no good to have encrypted messages and no keys." That sounds somewhat like [spoliation of evidence](http://en.wikipedia.org/wiki/Spoliation_of_evidence). Businesses are often required to retain documents for just this reason. Courts are unlikely to look favorably on "We couldn't help it. Our encryption algorithm automatically destroys the key." – Matthew Flaschen Jun 30 '10 at 06:29
  • @Matthew I think it only qualifies as "spoliation" if these documents are relevant to an **ongoing** legal proceeding. I believe email communication should be private, and current technology obviously offers little to no privacy. – quantumSoup Jun 30 '10 at 06:38
  • 1
    I still can't imagine a court looking favorably on a "sorry, your Honor, all our emails are automatically destroyed after they're read" kind of defense. – Dean Harding Jun 30 '10 at 06:41
  • I am not a legal expert, so I can't say for sure what the repercussions of doing that would be. But I just mentioned that as an example; this could have other uses. – quantumSoup Jun 30 '10 at 06:44
  • @Aircule, businesses are often required to retain documents to prepare for the *possibility* of litigation. See http://www.skocpa.com/document_retention_recommendation.htm, in particular "There is no retention limit for documents when fraudulent activity has occurred." If Enron didn't commit fraudulent activity, I don't know who did. – Matthew Flaschen Jun 30 '10 at 06:44
  • @Dean 'codeka' Harding: I don't see why. Any business entity has its right to protect the trade secrets information. There're certain kinds of documents that are required to be store by law - like bookkeeping for example, but all the rest is up to the business entity. The same way the business entity might institute a rule to shred all the paper documents once they are not necessary it can use 'self-destructing" mail. – sharptooth Jun 30 '10 at 06:44
  • 1
    @sharp, there's a huge difference between keeping trade secrets from competitors and destroying email because of possible future subpoenas. – Matthew Flaschen Jun 30 '10 at 06:46
  • 1
    @Matthew Flaschen: One would need to prove that email was destroyed to protect specifically against possible subpoenas, wouldn't they? – sharptooth Jun 30 '10 at 06:49
  • @Matthew: I know there are documents businesses are required to keep, but I don't think most email correspondence are in that category. In fact, the Enron emails are widely available and often used as a real email dataset. I don't think there is a lot of documents they are legally obliged to keep in those. – quantumSoup Jun 30 '10 at 06:49
  • @Matthew Flaschen: Also, the phrase "There is no retention limit for documents when fraudulent activity has occurred." definitely refers to the case when there is an official investigation - the party is not allowed to destroy any documents regardless of their age while the investigation is in progress, but this is not in effect before the activity is suspected or discovered. – sharptooth Jun 30 '10 at 06:51
  • 1
    @Aircule: in Australia (and I assume many jurisdictions) electronic documents (e.g. email) are given the same consideration as paper/hard-copy documents. You could say that personal emails do not fall into that category, but then: a) you should not be using a business email address to send personal emails and b) that wouldn't have helped the Enron people where a lot of those emails *were* business-related and *were* discussing fraudulent activities. Of course, if you're doing what Enron were doing, then destroying evidence is probably the least of your worries! – Dean Harding Jun 30 '10 at 06:54

8 Answers8

1

(Disclaimer: I didn't read details on Vanish or the Sybil attack, which may be similar the what comes below)

First of all: Email messages are generally quite small, esp. compared to a 50 mb youtube vid you can download 10 times a day or more. On this I base the assumption that storage and bandwidth are not a real concern here.

Encryption, in the common sense of the word, introduces parts into your system that are hard to understand, and therefore hard to verify. (think of the typical openssl magic everybody just performs, but 99% of people really understand; if some step X on a HOWTO would say "now go to site X and upload *.cer *.pem and *.csr" to verify steps 1 to X-1, I guess 1 in 10 people will just do it)

Combining the two observations, my suggestion for a safe(*) and understandable system:

Say you have a message M of 10 kb. Take N times 10 kb from /dev/(u)random, possibly from hardware based random sources, call it K(0) to K(N-1). Use a simple xor operation to calculate

K(N) = M^K(0)^K(1)^...^K(N-1)

now, by definition

M = K(0)^K(1)^...^K(N)

i.e. to understand the message you need all K's. Store the K's with N different (more or less trusted) parties, using whatever protocol you fancy, under random 256 bit names.

To send a message, send the N links to the K's.

To destroy a message, make sure at least one K is deleted.
(*) as regards to safety, the system will be as safe as the safest party hosting a K.

Don't take a fixed N, don't have a fixed number of K's on a single node per message (i.e. put 0-10 K's of one message on the same node) to make a brute force attack hard, even for those who have access to all nodes storing keys.

NB: this of course would require some additional software, as would any solution, but the complexity of the plugins/tools required is minimal.

mvds
  • 45,755
  • 8
  • 102
  • 111
  • This is similar to what Vanish does; except you can tweak the number of key pieces you need to recover the message, and these key pieces are distributed among millions of nodes. – quantumSoup Jul 17 '10 at 17:50
1

The self-destructing part is really hard, because the user can take a screenshot and store the screenshot unencrypted on his disk, etc. So I think you have no chance to enforce that (there will always be a way, even if you link to an external page). But you can however simply ask the recipient to delete it afterwards.

The encryption is on the other hand is not a problem at all. I wouldn't rely on TLS because even when the sender and the client are using it, there might other mail relies who don't and they might store the message as plain text. So, the best way would be to simple encrypt it explicitly.

For example I am using GnuPG for (nearly) all mails I write, which is based on some asymmetric encryption methods. Here I know that only those I have given explicitly permission can read the mail, and since there are plug-ins available for nearly all popular MUAs, I'ts also quite easy for the recipient to read the mail. (So, nobody has to encrypt the mail manually and might forgot to delete the unencrypted message from the disk...). And it's also possible to revoke the keys, if someone has stolen your private key for example (which is normally encrypted anyway).

In my opinion, GnuPG (or alternatively S/MIME) should be used all the time, because that would also help to make spamming more difficult. But thats probably just one of my silly dreams ;)

tux21b
  • 90,183
  • 16
  • 117
  • 101
1

There are so many different ways of going about it which all have good and bad points, you just need to choose the right one for your scenario. I think the best way of going about it is the same as your 'most common' solution. The trusted third party should really be you - you create a website of your own, with your own authentication being used. Then you don't have to give your hypothetical keys to anyone.

You could use a two way certification method by creating your own client software which can read the emails, with the user having their own certificate. Better be safe than sorry!

Joel Kennedy
  • 1,581
  • 5
  • 19
  • 41
0

IMO, the most practical solution for the situation is using Pidgin IM client with Off-the-Record (no-logging) and pidgin-encrypt (end-to-end assymetric-encryption) together. The message will be destroyed as soon as the chat window is closed, and in emergency, you can just unplug the computer to close the chat window.

Lie Ryan
  • 62,238
  • 13
  • 100
  • 144
0

If the recipient knows that the message might become unreadable later and they find the message valuable their intention will be to preserve it, so they will try to subvert the protection.

Once someone has seen the message unencrypted - which means in any perceivable form - either as text or as screen image - they can store it somehow and do whatever they want. All the measures with keys and so one only make dealing with the message inconvenient, but don't prevent extracting the text.

One of the ways could be to use self-destructing hardware as in Mission Impossible - the hardware would display the message and then destroy it, but as you can see it is inconvenient as well - the recipient would need to understand the message from viewing it only once which is not always possible.

So given the fact that the recipient might be interested in subverting the protection and the protection can be subverted the whole idea will likely not work as intended but surely will make dealing with messages less convenient.

sharptooth
  • 167,383
  • 100
  • 513
  • 979
  • Again, I am not too worried about the recipient intentionally copying the message, but rather him/her having the diligence to delete it – quantumSoup Jun 30 '10 at 06:17
  • 2
    That won't work - once they have anything they find interesting they will keep it. If they see that information is very valuable they will go to length to backup the message so that it can be readable later. It's the same as with usual backups - you feel that something is valuable and you make a backup before it's gone. – sharptooth Jun 30 '10 at 06:18
  • I believe you are mistaking the intent of the asker and the point of his question. – Justin L. Jun 30 '10 at 06:19
  • Security always comes with a price. But it shouldn't make the recipient's life more difficult; a specialized client can open and create messages normally. The only hassle would be installing this. Most of the times emails that come back to haunt you aren't necessarily intentionally saved to begin with. Having this would just ensure these messages are rendered unreadable with no effort from the recipient. – quantumSoup Jun 30 '10 at 06:33
0

If HTML format is used, you can have the message reference assets that you can remove at a later date. If the message is open at a later date, the user should see broken links..

Don
  • 542
  • 3
  • 6
  • This is not acceptable since it will require a trusted third party that stores these assets. – quantumSoup Jul 13 '10 at 18:43
  • Any avenue is either 3rd party or your own and 99.9% of the 3rd parties will store the assets for an extended period of time. Using the HTML idea you could: break the email in segments, make each segment an image, encrypt each image, share key with recipient, store images on various 3rd party sites. Or you could spin up a virtual machine that has a frozen image when you need to send out these types of communications and have it return to the frozen state upon shutdown, no data stored. – Don Jul 13 '10 at 22:05
0

If your environment allows for it, you could use the trusted boot environment to ensure that a trusted boot loader has been used to boot a trusted kernel, which could verify that a trusted email client is being used to receive the email before sending it. See remote attestation.

It would be the responsibility of the email client to responsibly delete the email in a timely fashion -- perhaps relying on in-memory store only and requesting memory that cannot be swapped to disk.

Of course, bugs can happen in programs, but this mechanism could ensure there is no intentional pathway towards storing the email.

sarnold
  • 102,305
  • 22
  • 181
  • 238
0

The problem, as you describe it, does sound very close to the problem addressed by Vanish, and discussed at length in their paper. As you note, their first implementation was found to have a weakness, but it appears to be an implementation weakness rather than a fundamental one, and is therefore probably fixable.

Vanish is also sufficiently well-known that it's an obvious target for attack, which means that weaknesses in it have a good chance of being found, publicised, and fixed.

Your best option, therefore, is probably to wait for Vanish version 2. With security software, rolling your own is almost never a good idea, and getting something from an established academic security group is a lot safer.

Norman Gray
  • 11,978
  • 2
  • 33
  • 56