On Wed, 18 Aug 2004 vedaal(_at_)hush(_dot_)com wrote:
now that sha-0 has been broken,
SHA-0 was (theoretically) broken in 1998. The recent work is simply an
improvement in the break.
and sha-1 is actively being looked at for a possible extension of the
attack,
and MD5, HAVAL, and RIPEMD are also being attacked
http://eprint.iacr.org/2004/199.pdf)
Actually, all three are broken. But MD5 was (theoretically) broken in
1996, and RIPEMD has been considered weak for years. (Note, RIPEMD is
based on MD4. It is *not* the same as RIPEMD-160 (based on RIPEMD, but
with considerable input from Dobbertin, who broke MD4 and MD5, or
RIPEMD-128 (based on RIPEMD-160, intended as a "drop in" replacement for
RIPEMD or MD4/5.)
would it be reasonable to re-accept the non-sha based hashes, (e.g. TIGER)
as a potential backup hash for implementations/users that may wish to
begin doing so?
SHA-256 and SHA-512 are not based on the MDx family, and have arguably
gotten more scrutiny than TIGER. Even if SHA-1 or RIPEMD-160 were
threatened, we already have alternatives.
The bigger problem I see is with the lack of a sound hash function
firewall in OpenPGP v4 DSA keys. We can add all the strong hash functions
we want, but as long as there exists a weak hash function in the spec, an
attacker can theoretically cause a collision in the weak hash function to
match the strong hash function's results, and break the signature scheme.
We either need to fix this, drop DSA keys, require that all DSA keys
actually be DSS (and then deal with the consequences if SHA-1 is broken),
or standardize on a single hash (and have a backup hash ready if need be.)
Thinking about this more now, I suppose dropping DSA would be the
simplest, though that would cause a lot of compatibility issues.
On a different note, I'm also in favor of dropping backwards compatibility
with v3 in the spec, as I've mentioned before. This would also allow us to
easily drop MD5 from v4. I think any backwards compatibility is adequately
handled in the client implementations, and does not belong as a part of
the OpenPGP message format. (I.e., there are clients that offer S/MIME
compatibility, yet there's no reason for that to be part of this spec,
either. We already have RFC 1991.)
--Len.