In
<4(_dot_)3(_dot_)2(_dot_)7(_dot_)0(_dot_)20000822163657(_dot_)00af8850(_at_)mail(_dot_)comasp(_dot_)com>,
on 08/22/00
at 02:43 AM, Erron Criddle <ejc(_at_)comasp(_dot_)com> said:
At 01:33 PM 22/08/2000 +0900, sen_ml(_at_)eccosys(_dot_)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
---------------------------------------------------------------