public-key: the wrong model for email?

[Weger, B.M.M. de]

Hi Ed,

What about ID-based crypto: the public key can be any string, such as
your e-mail address. So the sender can encrypt even before the
recipient has a key pair. The private key is derived from the
public key by a trusted party when the recipient asks for it.
Yes, the recipient does have some burden here, but it seems to
me that that is unavoidable.
I'm not saying that this is without problems (private key distribution,
inherent key escrow / recovery, revocation issues), or that it's easier 
manageable than traditional PKI, but it may solve some of your issues.

The idea for ID-based crypto comes from Adi Shamir, back in 1984.
The first practical and mathematically sound realisation is due to
Boneh and Franklin (Crypto 2001), and is brought to the market
by Voltage (www.voltage.com). I don't know their products, only that
it exists, and I'm not a shareholder. I do think it's interesting
math and interesting crypto, and that it could lead to interesting 
technology.

Grtz,
Benne de Weger

========================================= 
Technische Universiteit Eindhoven 
Coding & Crypto Groep 
Faculteit Wiskunde en Informatica 
Den Dolech 2 
Postbus 513 
5600 MB Eindhoven 
kamer HG 9.84 
tel. (040) 247 2704, bgg 5141 
e-mail: b.m.m.d.weger at tue.nl 
www: http://www.win.tue.nl/~bdeweger 
========================================= 
 

> -----Original Message-----
> From: owner-cryptography at metzdowd.com 
> [mailto:owner-cryptography at metzdowd.com] On Behalf Of Ed Gerck
> Sent: woensdag 15 september 2004 20:39
> To: cryptography at metzdowd.com
> Subject: public-key: the wrong model for email?
> 
> [Perry: please use this version, if possible]
> 
> Public-key cryptography burdens the recipient and puts the 
> recipient in charge, while the sender is at the recipient's 
> mercy. Is this the right model for email security? After all, 
> the sender is the party at risk.
> 
> To clarify, my comment is not that PKC is not useful for 
> email. I believe it is, but not directly used as it is today.
> 
> What I am saying is that the problem is key distribution. I 
> want to separate the key distribution solution as directly 
> done by PKC today (send the public-key) from a possible 
> general solution for PKC key distribution that does not 
> require sending the public-key. The point is that when PKC 
> solves this problem directly, it solves it in a way that's 
> useful for webservers (the webserver does not have to trust 
> the client's certificate) but presents difficulties for email 
> senders (the sender has to trust the recipient's 
> certificate). Email use of PKC treats the recipient as a server.
> 
> I think that what we need is a key distribution method for 
> email (that can still use PKC and PKI) where, because the 
> sender has all the risk, the sender defines how email is 
> secured and delivered. The recipient should always be able to 
> receive it, without too much burden or required previous work.
> 
> For example, let's see how FedEx works. The sender chooses 
> the service and the type of envelope to protect the message. 
> The sender also chooses the instructions that must be 
> followed before the envelope can be opened by the recipient.
> The recipient has no charge to pay for, or burden, in order 
> to receive the envelope, and does not have to do anything 
> before the envelope is sent. The recipient is able to verify 
> the identity of the sender and, if so desired, refuse the 
> envelope. The recipient can open the envelope if and only if 
> the recipient is willing to follow the sender's instructions 
> (e.g., providing name, address, date, signature).
> 
> Yes, SSL and public-key encryption are and continue to be a 
> success for web servers. However, the security model for 
> protecting email with public-key cryptography seems to be 
> backwards, technically and business wise. The sender, who is 
> the party at risk, has to trust a lock provided by the recipient (his
> public-key) to protect her secrets (the message). If FedEx 
> would provide message security a la PGP, PGP/MIME or S/MIME 
> email, the sender would have to convince the recipient to pay 
> and send in advance an envelope for the sender to use.
> The sender, however, would never know whether the envelope 
> indeed prevented others from prying into its contents.
> 
> A better situation would arise if the lock (i.e., the 
> envelope) would be controlled by the sender. Moreover, the 
> recipient is not the business driver who needs to provide, 
> pay for and protect the lock. The sender is the party who has 
> the motivation to spend money to provide and protect the lock.
> 
> In short, I find that public-key cryptography cannot solve 
> the security issues of email when used as it is today and, 
> most importantly, cannot provide the needed motivation for 
> users, senders and recipients, to buy into it.
> 
> It's not a matter of improvements in usability, better 
> pricing or user education [1]. It simply does not work as it 
> should work. That's also why, IMO, it does not take off. It 
> is using the wrong mathematics for the problem.
> 
> Does anyone know of any email system that would put the 
> sender in charge?
> 
> Comments?
> 
> Cheers,
> Ed Gerck
> 
> [1] Public-key cryptography gives the impression that email 
> message security can be achieved quite simply. The public-key 
> can be distributed at will, no need for secrecy, and anyone 
> can receive private and secure messages. The same procedure 
> being applied to each side, sender and receiver, both could 
> immediately engage in private and secure communication.
> 
> 
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to 
> majordomo at metzdowd.com
> 

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