multiple subkeys and key transition

[Daniel Kahn Gillmor]

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

:P

> where do you see RIPEMD-160 in the scheme of things?

RIPEMD-160 is another 160-bit hash, same size as SHA-1.  I don't think
that it has undergone as extensive cryptanalysis as SHA-1; i'm sure
others on this list can give more intelligent commentary on its properties.

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).

> I ask because that seems to be the only update my current DSA/Elgamal
> key can accept (via setpref).

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).

But FIPS-186, as defined, only operates over 160-bit digests.  So longer
digest algorithms won't work with DSA1 keys.

> 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.  If that happens to re-ignite the WG discussion, that's
fine.  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.  (a preimage attack against SHA-1 would be
devastating, though)

 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)
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. :)

 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.

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

>> 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.

> 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.

> 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.

	--dkg

[0] http://www.itl.nist.gov/fipspubs/fip186.htm

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