Encrypted e-mail - comments by crypto-expert Bruce Schneier

By Joel Snyder
Network World on Groupware and Messaging, 09/08/99

Recently, Bruce Schneier - one of the top crypto-experts in the world - took time out to discuss Web-based encrypted e-mail. Bruce is the author of Applied Cryptography, the finest (nonclassified) work on cryptography and cryptographic algorithms ever published. If you've ever wanted to know about the guts of cryptography and how it all works, Bruce's book is the one to get (Amazon.com has it for $40). Bruce is also one of the authors of Twofish, which is one of the algorithms in competition to replace the venerable Data Encryption Standard as the U.S. national standard for encryption.

If you care about encryption, you should be getting Bruce's free e-mail newsletter, Crypto-Gram. I'll turn the microphone over to Bruce now for his take (Copyright (c) 1999 by Bruce Schneier) on Web-based encrypted e-mail:

The idea is enticing. Just as you can log on to Hotmail with your browser to send and receive e-mail, there are Web sites you can log on to to send and receive encrypted e-mail such as HushMail, ZipLip, YNN-mail, ZixMail. No software to download and install...it just works. But how well?

HushMail is basically a PGP or Secure Multi-purpose Internet Mail Extensions (S/MIME)-like e-mail application that uses Java (although oddly enough, HushMail is not compatible with either). The sender logs on to the HushMail Web site and encrypts messages using a Java applet that is automatically downloaded onto his machine. The sender and receiver need to have HushMail accounts for this to work. Accounts can be anonymous.

The algorithms are 1024-bit ElGamal for key exchange and signatures, and Blowfish for bulk encryption. But everyone's private key is stored on the HushMail server, protected in a passphrase. This means that one weak link is likely to be the passphrase; it's the only protection you have against someone who has legal or illegal access to the HushMail server. (The current beta -- August 99 -- doesn't let you change your passphrase, although they promise the feature in the future.)

Another weak link is the Java applet. When you download it, you have no idea if it is the correct applet. Yes, the source code is public, but that doesn't help when you are at a public Internet terminal trying to encrypt or decrypt private e-mail. A Trojaned Java applet can do all sorts of damage, and there is no way to know. Sure, you use a Secure Sockets Layer (SSL) connection between your computer and the HushMail server but if you don't actually check the details of the received certificate, you have no idea who you are connected to. HushMail is considering writing something to verify the applet automatically, but then how do you trust the verifier?

This is actually a major problem. The applet can be signed, but who signed it? Even if you check the certificate, the typical browser permits a dozen different public-key infrastructure roots by default, and any one of them can issue a forged certificate. This means you have to trust them all. And you have to trust that a Trojan didn't drop a phony certificate into your browser. Note that a downloaded verifier can never solve this problem; it just turns the "how do I trust the applet" question into "how do I trust the verifier."

And a third possible weakness is the location of the HushMail servers. Although the company is based in Antigua, the servers are located in Canada. Presumably Canada is more susceptible to legal attacks. And remember that the security depends on the physical protection of the HushMail server.

All in all, though, HushMail seems like a reasonable implementation of the idea. The company seems clued - it has a reasonably informative Web site and it responds promptly to security questions.

ZipLip is different. Both parties do not need an account to communicate. The sender logs on to the ZipLip Web site and, using SSL, sends a message to someone else. ZipLip then sends the recipient a message telling him that your message is waiting. The recipient then logs on to ZipLip to receive the message. Encryption, outside the two SSL connections, is completely optional.

ZipLip won't identify the encryption algorithm used, which is enough to discount them without further analysis. But they do something even stupider; they allow the sender to create an encryption key and then give the recipient a "hint" so that he can guess it. ZipLip's own Web site suggests: "The name of the project we're working on," or "The restaurant where we had dinner last night." Maybe there are 100,000 restaurants, so that's a 17-bit key.

The threats here are serious. The sender and receiver need to verify their SSL connections; otherwise there is no security. The ZipLip server is a major attack target because many messages will not be encrypted and those that are will have keys weakened by the requirement that both parties remember them.

On the plus side, ZipLip claims a policy of deleting all mail 24 hours after delivery, which provides a level of lawyer-proofing that HushMail does not have...if they implement it properly.

YNN-mail is barely worth this paragraph. It encrypts stored messages with a 40-bit key, and doesn't use SSL when you sign up and send them a long-term password. Snake oil if I've ever seen it. And I just heard of another, ZixMail. I didn't have time to examine it in depth but the FAQ - look at its wishy-washy comments on encryption - makes it sound like real snake oil, too.

Web-encrypted e-mail is less secure than PGP-encrypted e-mail (or S/MIME e-mail) for a few reasons. One, the constant interaction between the communicants and the server leaves more opportunity for man-in-the-middle attacks, Trojan horses and others. Two, SSL authentication is more vulnerable to spoofing, since almost no one ever bothers to check the details of received certificates and there is no revocation mechanism in place. And three, there are some very attractive attack targets: servers with large collections of secret e-mail and potential decryption keys. Certainly Web-based encrypted e-mail is better than unencrypted e-mail, but I'd stick with PGP or S/MIME if possible.

This essay was written with input from Fred Wamsley.