Voltage Security's identity-based encryption

Today, in order to exchange a secure electronic message it is necessary for the sender to go to a directory to find the recipient's public key. That public key is then used to scramble the message in such a way that only the recipient can read it by using a second, privately held key to unscramble it. [A Simpler, More Personal Key to Protect Online Messages, John Markoff, New York Times]

False. Today, I attach S/MIME signatures to all my outbound messages. The signature includes my public key. Thousands of recipients of messages from me could choose to encrypt messages to me, since they already have my public key. Of course, no-one does. Conversely, all six of the folks who have ever attached an S/MIME signature to a message sent to me have, by doing so, inserted their public keys into my mail client's keystore. I rarely choose to encrypt messages to one of these people, but when I do there is no need to look up a public key in a directory. I already have it.

You can't blame John Markoff for this error. Essentially no-one understands the suite of S/MIME signature and encryption capabilities built into the major email clients. Anyway, the real benefit of identity-based encryption, according to Voltage Security's writeup, is different, and interesting. It purports to do away with the need for certificates and certification authorities.

As detailed in its white paper, the Voltage scheme proposes to:

  1. Use email addresses, IM screennames, or other short mnemonic identity handles as public keys.

  2. Bind, to your email and IM applications, a module that retrieves private keys from a key server.

What's most attractive here is that users need not "pre-enroll" with a certification authority -- something that users have so far avoided like the plague.

I see a few problems. First, it supposes that a sender would choose to encrypt a message if the procedure's barrier to entry were lower. This fails the Ray Ozzie test for "complacency-immunity" -- the sender must still choose to encrypt, and given a choice almost none will.

Second, the scheme works bidirectionally only if both parties use Voltage's key server.

Then there's the question of what widespread encryption would do to an email infrastructure that has, rather suddenly, grown to depend on content analysis for spam detection.

A related issue: although we've never exploited it, the peer-to-peer nature of S/MIME or PGP key exchange creates an implicit whitelist. Today you are only likely to receive an encrypted email from someone you're previously written to. Imagine what might happen if spammers needed only your email address -- which they obviously already have -- to encrypt messages to you.

I could be wrong, maybe this really is the silver bullet. But, like Pito Salas, I am skeptical.

Update: Douwe Osinga writes:

On the other hand, encrypting a message is a relatively time consuming thing to do. It would make sending out millions of messages much harder, because each would have to be encrypted seperately. 0.1 sec per message would be okay for normal users, but if you need to send out 1 million messages to make one sale, it pretty much destroys your model.

Excellent point. It would be a kind of hashcash, wouldn't it?


Former URL: http://weblog.infoworld.com/udell/2003/07/08.html#a739