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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
