multiple subkeys and key transition

[Ben McGinnes]

On 10/12/10 6:12 AM, Daniel Kahn Gillmor wrote:
> On 12/09/2010 01:30 PM, Ben McGinnes wrote:
>> Ah, a debate, excellent.  Now let's make it a little more
>> entertaining,
> 
> :P

I'm glad I'm not the only one who likes to find answers this way.  :)

> RIPEMD-160 is another 160-bit hash, same size as SHA-1. 

For some reason I thought SHA-1 was 128-bit, but I've no idea why I
thought that.

> I don't think that it has undergone as extensive cryptanalysis as
> SHA-1;

That sounds an awful lot like security through obscurity.  Or, more to
the point, the absence of evidence is not evidence of absence (of a
security flaw).

> i'm sure others on this list can give more intelligent commentary on
> its properties.

Yeah, I'll get to Robert's response next.  ;)

> I prefer signatures made over digests longer than 160 bits (as do
> newer versions of gpg, which default to stating SHA256 as a
> preferred digest).

Which seems reasonable to me.

> That's probably because your primary key (the one doing signing and
> certifying) is a standard 1024-bit DSA key (the original DSA
> standard itself, FIPS-186 [0], specifies 1024 bit keylength --
> longer DSA keys come from later revisions of the standard, and are
> collectively known in gpg as DSA2, if i understand it correctly).

My current key was created at the end of 1998, I'm pretty sure that
DSA2 wasn't around then.  Back then the biggest argument was
maintaining compatibility with PGP 2.6.x (and earlier); when many
people would not update because of fears of backdoors being inserted
in software that was able to be exported outside of the United States.

Ah ... the Crypto Wars, how we don't miss them!

>> Is it possible that this current transition push is partially aimed at
>> reigniting the WG's discussion by creating a new de-facto standard?
>> In much the same way that PGP 5.x became the foundation for OpenPGP
>> (RFC 2440 and then 4880).
> 
> The transition push is to make sure we have a functional WoT
> available when SHA-1's collision-resistance is ultimately publicly
> broken in a practical attac. 

Okay.  My key doesn't have that many signatures, but I like the ones
I've got.  Still, I suppose the sanctity of my own signatures should
be of just as great, if not greater, concern.

> If that happens to re-ignite the WG discussion, that's fine.

Fair enough.

> AFAICT, the only cryptographically-relevant places where the current
> standard (RFC 4880) has SHA-1 "baked in" are:
>
>  0) the fingerprint-calculating mechanism
> 
>  1) the designated-revoker sub-packet, because it references the
> fingerprint.
> 
>  2) that SHA-1 is the only official "must-implement" digest algorithm
> 
> A defeat of SHA-1's collision-resistance shouldn't have an effect on
> point 0 because fingerprints are generated by a single party, on their
> own -- there's no way for me to convince you to generate a key with a
> specific fingerprint. 

Yep, okay.

> (a preimage attack against SHA-1 would be devastating, though)

I assume that there's still no indication of if and/or when that might
be viable?

I suppose a better question is: is a preimage attack against SHA-1
simply a matter of time?

>  The loose consensus seems to be that point 1 should be trivially
> resolvable by defining a new version of the designated-revoker
> subpacket that embeds the revoker's entire key (instead of just the
> fingerprint)

Is this why a revoked key can still be used to decrypt data that was
encrypted with a non-revoked copy of the key?

> but no one has done the work to make that happen yet.  This wouldn't
> even need a new version of the entire spec, it would just be an update
> to the spec, claiming a new subpacket type from IANA.  And an example
> implementation in a popular tool like GnuPG wouldn't hurt either, of
> course. :)

Why do I get the feeling that this bit is addressed to Werner ...  ;)

>  point 2 is a potential cause for concern, but in practice all OpenPGP
> implementations distributed in the last 5 years have been able to
> support SHA-256. 

> It seems like some folks in the OpenPGP WG would prefer to wait
> until NIST's SHA-3 contest's results are announced and settle on
> that outcome as a new must-implement digest for the next major
> revision of the standard.

Okay, I just looked that up and in spite of a tentative statement that
the final round would be announced this year, there doesn't appear to
be any statement on that front.  I suppose that could happen in the
next three weeks, but it could also mean delays in the process.

> But that shouldn't stop you from using stronger digests today.

Hmm, I'm beginning to be swayed again.

>>> This statement seems to assume that the RFC can't or won't be
>>> updated in a way that people could make the transition using the
>>> same key material, assuming they were using strong enough keys and
>>> digests in the first place.
>>
>> What is the likelihood of that actually being the case?
> 
> i don't know, but it doesn't seem out of the question to me.  There
> may need to be a translation (and possibly re-certifying) step to
> move existing strong keys to a new version when that comes out, but
> i don't think it should require discarding those keys.  Weak keys,
> on the other hand, will probably not be translatable.

This is somewhat encouraging.

>> 2) 4,096-bit RSA signing key with a 4,096-bit RSA encryption key and a
>> 4,096-bit Elgamal encryption key.
> 
> i don't see the advantage of having two encryption-capable subkeys
> myself, but it's your call.

I'm not sure I do either, which brings me back to the RSA vs. Elgamal
debate (and more reading).

>> Since I prefer a more long-term approach, this should eventually
>> lead to 8,192-bit encryption keys when 4,096-bit becomes the
>> default.  That's probably a fair way down the track, though, very
>> likely several years away.
> 
> i think we are at least as likely to switch to elliptic-curve as an
> asymmetric algorithm than to ever start defaulting to 4096- or
> 8192-bit RSA keys, but that's too far in the future for my crystal
> ball to see clearly.

I know better than to ask for that kind of prediction, especially with
EC possibly entering the arena.  Thanks.


Regards,
Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20101210/eb608e3d/attachment-0001.pgp>