Thoughts about the Personally Encrypted IMAP Storage proposal

When reading the Personally Encrypted IMAP Storage proposal, a couple of things came to my mind.

1) Why use public key crypto when you’re going to going to store the private keys on the servers? It’d be much simpler (safer) to encrypt the messages with symmetric crypto (like AES or Twofish) using the user password. Or maybe using something a bit fancier than the user password:

use Digest::SHA;
# user provides $password, $salt is a random number for each user stored in the DB
my $hash = $salt;
for (my $i=0; $i<256; $i++) {
$hash = hmac_sha1($password, $hash);
}
# encrypt using $hash

2) Since most MUA have PGP/GPG support, wouldn't it be nice to just encrypt the messages with the user's public key before they're stored in the maildir, and let the MUA decrypt them? That's more in line with the traditional way of designing public key crypto systems. One caveat would be that the headers would not be encrypted, but nothing stops you from implementing symmetric crypto on top of that (like discussed in 1).

3) All this would prevent snooping of mail already received, it wouldn't stop someone from putting a wiretap at the MTA level (or with your ISP) and read every new message received in the clear...

One Response to Thoughts about the Personally Encrypted IMAP Storage proposal

  1. Thanks for the comments.
    I think the most important thing would be to achieve that even if you sniff a login session (and the session key) once, you still shouldn’t be able to open the mailbox or read mails that weren’t accessed during the session (which, IIRC, they were forced to do at Hushmail).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>