Subject: re-consideration of TIGER

From: <[email-masked]>
Date: Wed, 18 Aug 2004 06:54:42 -0700

now that sha-0 has been broken,
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)

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?

vedaal

Concerned about your privacy? Follow this link to get
secure FREE email: http://www.hushmail.com/?l=2

Free, ultra-private instant messaging with Hush Messenger
http://www.hushmail.com/services-messenger?l=434

Promote security and make money with the Hushmail Affiliate Program: 
http://www.hushmail.com/about-affiliate?l=427

---

From: Lutz Donnerhacke <[email-masked]>
Date: Wed, 18 Aug 2004 14:41:56 +0000 (UTC)

> as a potential backup hash for implementations/users that may wish to

Unless the attack is not substantiated, wild actionism should be avoided.
Currently the attack looks like exploiting insufficient highest bit handling
of the internal state variables. This is a matter if the protocol applies a
random(!) padding directly before hashing.

---

From: Jon Callas <[email-masked]>
Date: Wed, 18 Aug 2004 09:36:40 -0700

> as a potential backup hash for implementations/users that may wish to

Not really, no. There are already perfectly good backup algorithms.

The reason we removed Tiger is that it hasn't been examined or used at 
all. None of these things apply to Tiger, and it is therefore still not 
well examined nor used. Going from a hash function that has been 
examined to one that hasn't isn't presently warranted.

SHA-1 isn't broken yet. Even the ones that have been broken haven't 
been broken (yet) in ways that permit signature forging. What we know 
now is that the functions we've been saying for close to a decade 
shouldn't be used really shouldn't be used.

If you're worried about SHA-1, you should move to SHA-256. Don't be 
scared by the fact that it's called "SHA."

If you want to do something *really* practical and good, stop using 
your V3 keys. (That's the editorial you, not vedaal specifically.)

I'm sitting in the hash sessions at Crypto now, and SHA-1 isn't broken. 
Again, if you still want to do something, start using SHA-256.

	Jon

---

From: Florian Weimer <[email-masked]>
Date: Wed, 18 Aug 2004 18:53:56 +0200

> Unless the attack is not substantiated, wild actionism should be avoided.

Agreed.

> Currently the attack looks like exploiting insufficient highest bit
> handling of the internal state variables. This is a matter if the
> protocol applies a random(!) padding directly before hashing.

Source?

Based on my extrapolation of the pseudo-paper, it also depends where
the padding is added, if some length information is protected by the
hash, and the overall purpose of the hash function.  While MD5 has
certainly been broken, this doesn't seem to lead to immediate attacks
on real protocols.

(The impact on V3 keys could be interesting, though.)

---

From: Lutz Donnerhacke <[email-masked]>
Date: Wed, 18 Aug 2004 19:20:07 +0000 (UTC)

>> protocol applies a random(!) padding directly before hashing.

Personal impression.

> (The impact on V3 keys could be interesting, though.)

Of course.

---

From: Len Sassaman <[email-masked]>
Date: Wed, 18 Aug 2004 13:49:51 -0700 (PDT)

> now that sha-0 has been broken,

SHA-0 was (theoretically) broken in 1998. The recent work is simply an
improvement in the break.

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

> as a potential backup hash for implementations/users that may wish to

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.

---

From: Ian Grigg <[email-masked]>
Date: Thu, 19 Aug 2004 00:20:24 +0100

> either. We already have RFC 1991.)

I'm in total agreement there.

With one caveat - the chair would have to ponder whether
"this late" in the spec there are major changes allowed.

Some mentioned that v3 may be compromised even more by
this recent message digest news, and if so, that would be
sufficient casus belli, IMHO, to seriously consider doing
such a major step.

iang

PS: I note the comment on DSA/DSS keys ... if the above
logic doesn't fly, I'd suspect there is no case to drop
those keys, but I'm listening :-)