
dshaw at jabberwocky
Jun 24, 2012, 6:08 AM
Post #4 of 4
(233 views)
Permalink
|
On Jun 24, 2012, at 1:10 AM, Daniel Kahn Gillmor <dkg [at] fifthhorseman> wrote: > On 06/23/2012 04:41 PM, David Shaw wrote: >> Yes, this makes sense. GPG won't generate a subkey on a V3 key (or a V3 subkey at all), but might accept them if generated elsewhere. So you had to patch things to make the key, but no patch is needed to use the key. > > Of course, the opportunity for compromise comes when a victim *uses* of > the key, not from its creation. So while i appreciate the refusal of > GPG to generate these keys (which means one less tool available to an > attacker for the creation of the colliding key), it doesn't really > address the fact that users of GPG are at risk if they deal with keys > generated elsewhere. I don't think anyone is arguing that it does. Georgi and I were just discussing why he was able to get the results he did, using a hacked GPG to create keys and an unpacked one to use them. Werner suggested one real fix at the top of this thread - ignore all v3 keys by default. Alternately, there are checks that can be done when there are multiple possible matching keys. The latter fix also addresses a possible v4-v4 collision, which is a nice benefit, but is a more invasive change. Either way, a fix is being discussed. David _______________________________________________ Gnupg-devel mailing list Gnupg-devel [at] gnupg http://lists.gnupg.org/mailman/listinfo/gnupg-devel
|