NPR : E-Mail Encryption Rare in Everyday Use

Ben Laurie ben at
Fri Mar 3 00:58:46 EST 2006

alex at wrote:
>> ----- Original Message -----
>> From: "Ben Laurie" <ben at>
>> To: alex at
>> Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
>> Date: Thu, 02 Mar 2006 10:16:55 +0000
>> alex at wrote:
>>>> Alex Alten wrote:
>>>>> At 05:12 PM 2/26/2006 +0000, Ben Laurie wrote:
>>>>>> Alex Alten wrote:
>>>>>>> At 02:59 PM 2/24/2006 +0000, Ben Laurie wrote:
>>>>>>>> Ed Gerck wrote: We have keyservers for this (my chosen
>>>>>>>> technology was PGP). If you liken their use to looking up an
>>>>>>>> address in an address book, this isn't hard for users to grasp.
>>>>>>> I used PGP (Enterprise edition?) to encrypt my work emails to 
>>>>>>> a distributed set of members last year.  We all had each 
>>>>>>> other's
>>>>>>> public keys (about a dozen or so).
>>>>>>> What I really hated about it was that when fred at sent
>>>>>>> me an email often I couldn't decrypt it.  Why?  Because his
>>>>>>> firm's email server decided to put in the FROM field
>>>>>>> "fred at". Since it didn't match the email name
>>>>>>> in his X.509 certificate's DN it wouldn't decrypt the S/MIME
>>>>>>> attachment. This also caused problems with replying to his email.
>>>>>>> It took us hours, with several experimental emails sent back and
>>>>>>> forth, to figure out the root of the problem.
>>>>>>> No wonder PKI has died commercially and encrypted email is on the
>>>>>>>  endangered species list.
>>>>>> I trust you don't think this is a problem with PKI, right? Since
>>>>>> clearly the issue is with the s/w you were using.
>>>>> I place the blame squarely on X.509 PKI.  The identity aspect of it
>>>>> is all screwed up. No software implementation can overcome such a
>>>>> fundamental architectural flaw.
>>>> OK - I'll bite - why does the sender's identity have any impact on the
>>>> recipient's ability to decrypt?
>>> Because the software needs a unique ID/name to find the correct 
>>> key to use. In practice (corporate) users can have multiple email 
>>> names, see my reply to Peter Gutman.  This is not the fault of 
>>> the email architecture, which has been working fine for 30-40 
>>> years, but the fault
>>> of the X.509 architecture trying to piggyback on an address/name 
>>> space that is not designed with security/cryptography 
>>> considerations in mind.
>> I have to admit to not being familiar with S/MIME, but the usual
>> practice is to identify the signing key in the signature. Certainly this
>> is what OpenPGP does. Its also kinda weird to refuse to decrypt just
>> because the signature can't be verified.
> How does OpenPGP identify the signing key in the incoming email's signature?

Here's the output of one of the example programs in OpenPGP:SDK
(, showing the structure of an OpenPGP
signed file. I trust it is self-explanatory.

==== ptag new_format=0 content_tag=8 length_type=3 length=0x0 (0)
position=0x0 (0)
Compressed Data Type: 1

==== ptag new_format=0 content_tag=4 length_type=0 length=0xd (13)
position=0x0 (0)
Version: 3
Signature Type: Signature of a binary document (0x0)
Hash Algorithm: SHA1 (0x2)
Public Key Algorithm: RSA (Encrypt or Sign) (0x1)
Signer ID: 0x8337FE6485F4ED64
Nested: 1

==== ptag new_format=0 content_tag=11 length_type=0 length=0x22 (34)
position=0xf (15)
  literal data header format=b filename='to-be-signed'
    modification time=1141297085 (Thu Mar  2 10:58:05 2006)
  literal data body length=16
To Be Signed.

==== ptag new_format=0 content_tag=2 length_type=1 length=0x95 (149)
position=0x33 (51)
Signature Version: 3
Signature Creation Time: time=1141297085 (Thu Mar  2 10:58:05 2006)
Signature Type: Signature of a binary document (0x0)
Signer ID: 0x8337FE6485F4ED64
Public Key Algorithm: RSA (Encrypt or Sign) (0x1)
Hash Algorithm: SHA1 (0x2)
hash2: 0xBF33


"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

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

More information about the cryptography mailing list