dshaw at jabberwocky
Jun 24, 2012, 6:08 AM
Post #4 of 4
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.
Gnupg-devel mailing list
Gnupg-devel [at] gnupg