In <v04001d09b06cea8d4a97(_at_)[205(_dot_)180(_dot_)137(_dot_)244]>, on
10/17/97
at 04, Will Price <wprice(_at_)pgp(_dot_)com> said:
Well I really have to say that I don't like this. It basically blows
months of work in the area of keylookup optimization techniques that I
have developed for my products. Due to the uniqueness of the keyid in a
given keyring
This has never actually been a valid assumption in old PGP, and is only a
reasonably valid assumption in 5.0+ with the 64bit keyIDs, so "months" of
work which depended on this seems based on an error. We have seen both
0xdeadbeef keys and actual random collisions in the old RSA keys. The
security reasons for combining the KeyID and Fingerprint and thus being
able to take advantage of the extra size and security were very well laid
out by Hal.
Of courese this is a valid assumption, PGP does not allow the addition of
a key to a keyring if that keyid is already found in the keyring, therfore
it is safe to assume that for a given keyring all keyids are unique. We
are not talking of using the keyID for determining the authentication of a
key merly for doing keylookup before processing a encrypt/sig block. I am
well aware of a varity of spoof attacks on the PGP keys and have written
on them in the past.
Variable KeyId's blow KeyId uniqueness out of the water. should id 123456,
id 5456, & id 456 be considered three unique keys or two unique keys ??
I think you must have misunderstood something about Hal's message. The
KeyID in the *key* is never variable. As Hal outlined, RSA keys use the
old 32bit method, and DSS/DH keys use the new fingerprint/keyID 160/64
bit method. We're only really talking about the ESK packet on encrypted
messages here for variable size keyIDs. The issue is how much
information to reveal there. The one thing that wasn't implemented in
5.0/5 was the small key ID size ESK Hal described -- I'd never heard it
but it sounds a truly great idea from a privacy perspective. Sometimes
it is far more important to have deniability for privacy reasons than
incur the extremely unlikely possibility of going through the extra
milliseconds of trying more than one private key, and the few bits will
solve at least 95% of the cases in one try.
Well there are two points here:
1. Will a decreased size keyID really provide your goal of deniability??
As I posted in my last message if the goal is anonymidity the the solution
is to provide no keyID at all.
2. By having a limited or no keyID in the encryption packet, the end user
is denighed the knowledge of who the message was encrypted to. Was the
company key used? Was a government key covertly added?
I hope you can see how these two different needs are in conflict. I don't
see the reduced keyID as being a solution to either one. It does not
provide the needs of those whishing anonymitity nor does provide enough
information for the user who wishes to know who his communications has
been encrypted too.
It should be noted that Hal never mentioned where or how Phil whished to
make use of these variable size keyID's. I still stand by my original
conclution that the cost benifit case needs to be made on this before such
a departure from the curent keyID structure is made.
As an added note what effects will theis have on backward compatibility??
While the the breaking of compatibility was grudgingly accepted with 5.x
and the DSS/DH keys I doubt that same will be true for less benificial
"features".
Key Server Identifiers & URL's are of only limited use (communicating to
the keyservers).
Seems pretty darn useful to me. Bob has a key. It is on one server out
of thousands of keyservers. Which one? Who knows! Fortunately, Bob's
key hint tells me that his key is available for updates (revocations, new
signatures, new user IDs, etc...) from ldap://keyserver.company.com. The
old system of one big monstrous keyserver at MIT has been eliminated with
5.5 along with innumberable other improvements to the keyserver
infrastructure which will soon become apparent as we have time to get all
the information properly written up and everyone gets a chance to play
with 5.5 soon when we release the Personal version. This URL hint idea
was not implemented in 5.5. Easy to add.
Will, we have already disscused adding URL's and such to the key format
via the userID with a type identifier flag and some internal format
checking. I am assuming this is what you are talking about or are you
sugesting something different here? Regardless it is still of limited
value as it is only of use durring a keylookup on the *server* and then
only if you already have a copy of the key. The majority of
communincations to the server are not going to be for updated keys but for
an origianl copy of the key. In such a case all the person will have to go
on is the e-mail address and perhaps the keyID if a previously signed
message has been obtained.
--
---------------------------------------------------------------
William H. Geiger III http://www.amaranth.com/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://www.amaranth.com/~whgiii/pgpmr2.html
---------------------------------------------------------------