Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: GnuPG: devel

Re: v3 subkeys and signatures

 

 

GnuPG devel RSS feed   Index | Next | Previous | View Threaded


wk at gnupg

Jun 22, 2012, 10:33 AM

Post #1 of 4 (242 views)
Permalink
Re: v3 subkeys and signatures

On Fri, 22 Jun 2012 18:40, dshaw [at] JABBERWOCKY said:

> ("....MAY accept or reject them as it sees fit.") so that's fine. I'd
> have it ignore V3 keys by default (while still allowing decryption),
> but allow users to turn full V3 use back on if they must.

I fully agree. We always provided compatibility switches. What do you
think? Shall we use the --pgp2 option for this as well, or shall we add
another one?


Salam-Shalom,

Werner

--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


dshaw at jabberwocky

Jun 22, 2012, 7:51 PM

Post #2 of 4 (235 views)
Permalink
Re: v3 subkeys and signatures [In reply to]

On Jun 22, 2012, at 1:33 PM, Werner Koch <wk [at] gnupg> wrote:

> On Fri, 22 Jun 2012 18:40, dshaw [at] JABBERWOCKY said:
>
>> ("....MAY accept or reject them as it sees fit.") so that's fine. I'd
>> have it ignore V3 keys by default (while still allowing decryption),
>> but allow users to turn full V3 use back on if they must.
>
> I fully agree. We always provided compatibility switches. What do you
> think? Shall we use the --pgp2 option for this as well, or shall we add
> another one?

Hmm. I think a new option for this, which --pgp2 would also set. The reason is that if someone has to use a v3 key (either wisely or not) it seems better to not force them to take the algorithm restrictions like MD5 that come along with --pgp2.

David


_______________________________________________
Gnupg-devel mailing list
Gnupg-devel [at] gnupg
http://lists.gnupg.org/mailman/listinfo/gnupg-devel


dkg at fifthhorseman

Jun 23, 2012, 10:10 PM

Post #3 of 4 (233 views)
Permalink
Re: v3 subkeys and signatures [In reply to]

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.

--dkg
Attachments: signature.asc (1.01 KB)


dshaw at jabberwocky

Jun 24, 2012, 6:08 AM

Post #4 of 4 (233 views)
Permalink
Re: v3 subkeys and signatures [In reply to]

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

GnuPG devel RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.