NPR : E-Mail Encryption Rare in Everyday Use

[Ben Laurie]

alex at alten.org wrote:
>> ----- Original Message -----
>> From: "Ben Laurie" <ben at algroup.co.uk>
>> To: alex at alten.org
>> Subject: Re: NPR : E-Mail Encryption Rare in Everyday Use
>> Date: Thu, 02 Mar 2006 10:16:55 +0000
>>
>>
>> alex at alten.org 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 company.com 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 server.company.com". 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
(http://openpgp.nominet.org.uk/), 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 packet
Compressed Data Type: 1

==== ptag new_format=0 content_tag=4 length_type=0 length=0xd (13)
position=0x0 (0)
ONE PASS SIGNATURE packet
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 packet
  literal data header format=b filename='to-be-signed'
    modification time=1141297085 (Thu Mar  2 10:58:05 2006)
LITERAL DATA BODY packet
  literal data body length=16
    data=
To Be Signed.



==== ptag new_format=0 content_tag=2 length_type=1 length=0x95 (149)
position=0x33 (51)
SIGNATURE packet
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
sig=7344970C0DF62B089E79FFF024137E9D7D8919B6B1F1F29F3CCE8CD34625759EC181452C1A17858E418BA838FD3FED6AD013E7562F0B4E87BCA81D82D22B825A3ED6447E0F31F14DE0321554D558CEDCC339424ADA01B7C7374BBC59DE54E6BE4670D9D9E6FAC6412E927545DF1D2F0A373BFE6D058893CF675554F2DF8BE079

-- 
http://www.apache-ssl.org/ben.html           http://www.links.org/

"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 metzdowd.com