public-key: the wrong model for email?

Anne & Lynn Wheeler lynn at
Thu Sep 16 12:42:37 EDT 2004

At 11:19 PM 9/15/2004, Ed Gerck wrote:
>Yes, PKC provides a workable solution for key distribution... when you
>look at servers. For email, the PKC solution is not workable (hasn't been)
>and gives a false impression of security. For example, the sender has no
>way of knowing if the recipient's key is weak (in spite of its length)
>or has some "key-access" feature. Nonetheless, the sender has to use that

the issue then is what level do you trust the recipient, what is the threat 
model, and what are the countermeasures.

if there is a general trust issue with the recipient (not just their key 
generating capability) ... then a classified document compromise could 
happen after it has been transmitted. you may have to do a complete audit & 
background check of the recipient before any distribution of classified 

if the threat model is purely the document transmission, and you worry only 
about the recipient's key generating capability being up to the task of 
protecting the document transmission ... but you otherwise aren't worried 
about other trust issues with the recipient ... then go for 3rd party 
secure transmission service ... say where the encrypted package is 
delivered to the recipient and the recipient has to do some sort of 
real-time retrieval from the 3rd party of the package encryption key.

in the physical world ... there still could be the issue that the delivery 
address for the recipient (to be used by the 3rd party delivery service) 
might not be trusted.

part of the problem with introducing trust issues involving any specific 
recipient issue starts a real slippery slope  .... since the security of 
the system is all of the infrastructure .... and just addressing a single 
recipient trust issue (like key generation strength) .... still leaves open 
all sorts of other recipient trust issues.

say you have 3rd party encryption and secure delivery ...  with the 
possibility that the electronic package might be evesdropped (copied but 
not decoded). the issue then is how does the 3rd party know that the 
correct recipient is the only one that obtains the correct decryption key. 
there has to be some trust at some point that the correct recipient and 
only the correct recipient can decode any encrypted electronic package. at 
some point there has to be some flavor of trusting some sort of recipient 
authentication mechanism.

either the sender has it before hand (like the recipient's public key) or 
there is some sort of post-transmission authentication of the recipient. 
eliminating the requirement for strong authentication of the recipient 
before the transmission doesn't really eliminate the problem, it just moves 
it to some point.

Anne & Lynn Wheeler 

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list