Protection mail at rest

[Leichter, Jerry]

At one time, mail delivery was done to the end-user's system, and all
mail was stored there.  These days, most people find it convenient to
leave their mail on a IMAP server:  It can be accessed from anywhere,
it can be on a system kept under controlled conditions (unlike a
laptop), and so on.  In fact, most people these days - even the
technically savvy - not only leave their mail on an IMAP server,
but let some provider deal with the headaches of maintaining that
server.

So, most people's mail spends most of its life sitting on a disk owned,
managed, and controlled by some third party, whose responsibilities, not
to mention abilities, for keeping that stuff secure are unclear to say
the least.  On top of that, the legal protections for data held by a
third party are limited.

We have mechanisms for providing end-to-end encryption of messages.
Messages sent using, say, S/MIME are encrypted on the IMAP server
just as they are out on the net.  But this only helps for mail
exchanged between correspondents who both choose to use it.

Suppose I ask for a simpler thing:  That my mail, as stored in my
IMAP server, spends "most of its life" encrypted, inaccessible even
to whoever has access to the physical media on which the server
stores its mail.

Now, this is a funny goal.  If mail arrives unencrypted, anyone with
access to the data stream can copy it and do what they like.  It will
inevitably be buffered, even likely stored on a disk, in the raw,
unencrypted form.  We explicitly leave dealing with this out of the
equation - only end-to-end encryption can deal with it.

Here are two ways of implementation something in this direction:

 	1.  Client only.  The client, whenever it sees a new message,
 		(a) downloads it; (b) encrypts it using a secret key;
 		(c) stores the encrypted version back on the server;
 		(d) deletes the unencrypted version.  The client can
 		put the encrypted messages in a different folder, or
 		it can mark them with a header line.

 	2.  Server-assisted.  The client gives the server its public
 		key.  When a message arrives at the server, the
 		server (a) generates a "session" key; (b) encrypts
 		the message using the session key; (c) encrypts
 		the session key with the client's public key;
 		(d) adds a header containing the encrypted session
 		key to the encrypted message; (e) stores the
 		encrypted message.  The necessary work for
 		the client is obvious.

In each case, one would probably chose some headers to encrypt
separately - e.g., the subject - so that one could more easily pull
them out without decrypting the whole message.

Obviously, approach 2 greatly decreases the time that messages may
hang around unencrypted; but approach 1 can be implemented without
any cooperation from the IMAP provider, which allows it to be rolled
out even for those who use the large providers without having Google
and Hotmail and Yahoo! buy into it.

Does anyone know of existing work in this area?
 							-- Jerry

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com