Mailing List Archive: GnuPG: devel

v3 subkeys and signatures (was: Using second keyring may be)

Index | Next | Previous | View Threaded

wk at gnupg

Jun 22, 2012, 2:10 AM

Post #1 of 8 (278 views)
Permalink

v3 subkeys and signatures (was: Using second keyring may be)

On Fri, 22 Jun 2012 05:57, dkg [at] fifthhorseman said:

> colliding at how many trailing bits? what happens if you use
> "--keyid-format long"?

The problem is that the colliding key is a v3 key (MD5 fingerprint). It
is easy to create key id collissions for such keys; that is the reason
that back in the time of PGP 2 folks were used to compare the creation
date and key size.

If we list 0BFB847F3F272F5 we see a couple of irregularities:

pub 1024R/0BC39F3FB1C08810 2012-06-14
Key fingerprint = C42E F0DA 1A9C 27FA 5032 D7CB 0BC3 9F3F B1C0 8810
uid kkkkkkk5 <k@k>
sig!3 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 <k@k>
sig% 0BFB847F3F272F5B 2012-06-14 [Time conflict]
sig! 0BFB847F3F272F5B 2012-06-14 kkkkkkk5 <k@k>
sub 1024R/C3A7416F0354AE88 2012-06-14
Key fingerprint = 2F55 379F 8AB0 E8F1 D2BB 7EAF C3A7 416F 0354 AE88
sig! 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 <k@k>
sub 2179R/0BFB847F3F272F5B 2012-06-14
Key fingerprint = 7F C0 FE A6 A0 11 78 5A 06 7A CA CE A4 D7 12 80
[Note: a v3 key with a uncommon key size!]
sig! 0BC39F3FB1C08810 2012-06-14 kkkkkkk5 <k@k>

pub 4096R/0BFB847F3F272F5B 2007-11-09
Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B
uid Ubuntu Archive Master Signing Key <ftpma[...]
sig!3 0BFB847F3F272F5B 2007-11-09 kkkkkkk5 <k@k>

pub 4096R/0BFB847F3F272F5B 2007-11-09
Key fingerprint = 153F 1C9E F139 5FBF 0035 2E8D 0BFB 847F 3F27 2F5B
uid Ubuntu Archive Master Signing Key <ftpma[...]
sig!3 0BFB847F3F272F5B 2007-11-09 kkkkkkk5 <k@k>

Because GPG uses the (long keyid) to lookup the key in its internal
database it is prone to these errors. The first â€śsig%â€ť is due to
checking against the wrong key. The double listing the Ubuntu key has a
similar cause.

To mitigate the problem we should consider to forbid v3 subkeys. That
is to ignore v3 subkeys in cases where a subkey is expected. I have not
checked the RFC whether they are allowed, but they make no sense.
Actually it can be considered a bug: We have a strong (SHA-1) primary
key but allow a week (MD5) subkey.

We might also consider to ignore all v3 keys. After all MD5 is broken
and such keys should not be used anymore. One exception is to allow
decryption using a v3 key. Importing a v3 secret key will continue to
work, but v3 public keys would be skipped during import.

A complete solution to this problem would be a v5 signature packet
format to put the entire fingerprint into the signature packet. However
this breaks backward compatibility and thus will take a few years before
those signatures become mainstream.

If we expect v4 long key id collisions to occur more often in the
future, we should implement a workaround. For example we could store
the fingerprint for a signature packet in the meta data after we
successfully verified a signature the first time. Key lookups would
then use the fingerprint if available in the signature packet meta
data.

Shalom-Salam,

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, 9:40 AM

Post #2 of 8 (269 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

On Jun 22, 2012, at 5:10 AM, Werner Koch wrote:

> Because GPG uses the (long keyid) to lookup the key in its internal
> database it is prone to these errors. The first “sig%” is due to
> checking against the wrong key. The double listing the Ubuntu key has a
> similar cause.
>
> To mitigate the problem we should consider to forbid v3 subkeys. That
> is to ignore v3 subkeys in cases where a subkey is expected. I have not
> checked the RFC whether they are allowed, but they make no sense.
> Actually it can be considered a bug: We have a strong (SHA-1) primary
> key but allow a week (MD5) subkey.

It falls out like this - V3 keys can be a subkey on a V4 key (though a V3 can't be a primary and have subkeys of their own), but it's sort of moot since V3 keys are MUST NOT generate. So this key is legal format-wise (though obviously manipulated).

> We might also consider to ignore all v3 keys. After all MD5 is broken
> and such keys should not be used anymore. One exception is to allow
> decryption using a v3 key. Importing a v3 secret key will continue to
> work, but v3 public keys would be skipped during import.

I strongly agree with this. It's legal to ignore V3 keys in the spec ("....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.

David

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

lists-gnupgdev at lina

Jun 22, 2012, 10:01 AM

Post #3 of 8 (269 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

Am 22.06.2012, 11:10 Uhr, schrieb Werner Koch <wk [at] gnupg>:

> The problem is that the colliding key is a v3 key (MD5 fingerprint). It
> is easy to create key id collissions for such keys

Wonder if it would be possible to find all keys with this keyid with the
API and in case of signature validation to try all of them? (and then in
turn base the decision on the right one... hmm).

Bernd
--
http://bernd.eckenfels.net

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

wk at gnupg

Jun 22, 2012, 1:55 PM

Post #4 of 8 (268 views)
Permalink

Re: v3 subkeys and signatures [In reply to]

On Fri, 22 Jun 2012 19:01, lists-gnupgdev [at] lina said:

> Wonder if it would be possible to find all keys with this keyid with
> the API and in case of signature validation to try all of them? (and

Sure this is possible. The main problem will be to decide what error
message to print in case no key results in a good signature.

Shalom-Salam,

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

guninski at guninski

Jun 22, 2012, 11:49 PM

Post #5 of 8 (268 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

On Fri, Jun 22, 2012 at 12:40:23PM -0400, David Shaw wrote:
>
> .... V3 can't be a primary and have subkeys of their own)

This is not entirely correct.

Technically v3 may have subkeys (after patching gpg) - check the
keyring "fake4" that I posted on this list.

Not sure if v3 subkeys are usable though - maybe gpg needs more
patching to sign with them.

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

dshaw at jabberwocky

Jun 23, 2012, 6:21 AM

Post #6 of 8 (272 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

On Jun 23, 2012, at 2:49 AM, Georgi Guninski <guninski [at] guninski> wrote:

> On Fri, Jun 22, 2012 at 12:40:23PM -0400, David Shaw wrote:
>>
>> .... V3 can't be a primary and have subkeys of their own)
>
>
> This is not entirely correct.
>
> Technically v3 may have subkeys (after patching gpg) - check the
> keyring "fake4" that I posted on this list.

Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :)

> Not sure if v3 subkeys are usable though - maybe gpg needs more
> patching to sign with them.

They should be (at least in 1.4 they were). I haven't tried it in 2.x recently.

David

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

guninski at guninski

Jun 23, 2012, 6:59 AM

Post #7 of 8 (268 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

On Sat, Jun 23, 2012 at 09:21:05AM -0400, David Shaw wrote:
> Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :)
>

I meant patched gpg generated the keys, testing was done with vanilla gpg.

For me fake4 *allows* v3 subkeys of v3 keys. Checked with vanilla 1.4.12
and 2.0.19.

Have you tested fake4 (attached again)?

I might be missing something.

Attachments:

fake4 (1.64 KB)

dshaw at jabberwocky

Jun 23, 2012, 1:41 PM

Post #8 of 8 (270 views)
Permalink

Re: v3 subkeys and signatures (was: Using second keyring may be) [In reply to]

On Jun 23, 2012, at 9:59 AM, Georgi Guninski <guninski [at] guninski> wrote:

> On Sat, Jun 23, 2012 at 09:21:05AM -0400, David Shaw wrote:
>> Yes. Werner and I were discussing this in the context of the OpenPGP spec. In OpenPGP, v3 keys cannot have subkeys (it's in section 11 - "V3 keys MUST NOT have subkeys"). GPG actually allowed this for a while until the spec was changed. If you patch the code, you can of course make it do anything you want :)
>>
>
>
> I meant patched gpg generated the keys, testing was done with vanilla gpg.

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.

David

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads