[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mail client implementations problem? bcc and encrypting to multiple recipients



In <4.3.2.7.0.20000822163657.00af8850@mail.comasp.com>, on 08/22/00 
   at 02:43 AM, Erron Criddle <ejc@comasp.com> said:

>At 01:33 PM 22/08/2000 +0900, sen_ml@eccosys.com wrote:

><snip>

>>   since this means that each recipient receives a message containing a
>>   public key encrypted session key packet for each recipient, each recipient
>>   is able to tell who all of the recipients were (assuming no use of
>>   speculative key ids) -- or at least all key ids.
>>
>>   even if speculative key ids were to be used, a recipient would likely
>>   be able to tell that there were other recipients than those implied
>>   in the headers of a message.  also, afaik, nai pgp doesn't support
>>   speculative key ids, so in terms of interroperability it's not a great
>>   option at this point.

>As far as I'm concerned the Key ID is a complete waste of time unless a 
>lookup is being made on a server that is automatically decrypting each 
>message. This is OK here because you can configure the database to store 
>the Key ID and that makes lookups easier (if there are no duplicate Key 
>ID's). From my understanding of the Public and Private Keyring
>structures,  you can only have a Key ID for the highest level key (self
>sig.) and cannot  store the Key ID's for the subkeys.

>For our client software, we are not doing lookups via the Key ID (as it 
>isn't stored in the public/private keyrings), however the server version 
>will support lookups via Key ID's.

>We have found it better just to do lookups via the User ID - at least you
> can store that within the private /public keyring structures.

>If anyone can tell me otherwise regarding the storage of Signing and 
>Encryption Key ID's within the private/public keyrings, it would be
>great.


    IMHO using the userID is *not* the way to go. While userID lookups can be used the first time you are encrypting a message to a new e-mail address precautions need to be made. A dialog between the user should be established to verify that this is the actual key that should be used (anyone can create a key with any userID, multiple keys with the same userID may be present, ...ect). Key lookups need to be based on the 64bit keyID, it's the only way to insure that you are getting the correct key (for signature verifications it is the only way to find the key). Once a user has selected a key to use for a new e-mail address the application should store the 64bit keyID & the e-mail address in a table. For subsequent encryptions to that address the application should lookup the e-mail address in the table and then extract the PGP public key from the keyring using the corresponding keyID.

    Now granted the keyID is not stored in the key itself, this is not really that big of an issue. I can currently process a 1Gb keyring, calculating all the keyID's, in a couple of mins. For an average size keyring the processing time is less that a second. If you find your application needs to work with large keyrings maintaining a simple external index on the keyring by keyID will greatly improve performance.


-- 
---------------------------------------------------------------
William H. Geiger III      http://www.openpgp.net  
Geiger Consulting    

Data Security & Cryptology Consulting
Programming, Networking, Analysis
 
PGP for OS/2:               http://www.openpgp.net/pgp.html
E-Secure:                   http://www.openpgp.net/esecure.html
---------------------------------------------------------------