Subject: RE: [Cfrg] Who needs collision-resistance, anyway?

From: "Doug Whiting" <[email-masked]>
Date: Fri, 18 Mar 2005 11:58:18 -0800

Also, from a performance standpoint (given implementation numbers I've seen), SHA256 is ~2x slower than SHA1, and SHA512 is ~5x slower. So, if hash performance is truly critical (as some have argued here) in these applications, then that does not argue in favor of SHA256/SHA512. The reasons for using SHA256+ must be cryptographic, not performance based.

________________________________

From: [email-masked] on behalf of David Wagner
Sent: Fri 3/18/2005 11:35 AM
To: [email-masked]
Subject: Re: [Cfrg] Who needs collision-resistance, anyway?

D. J. Bernstein wrote:
>Exercise for the reader: SHA-512 has been a standard for years, and is
>obviously vastly more difficult to break than MD5 and SHA-1. Can you
>explain why so few people are using it?

I don't know how others choose between hash functions, but I can tell you
some of my reasoning, if that is relevant.  I know SHA1 well; I have spent
time trying to cryptanalyze SHA1; I have spoken to others who have done
the same.  I can't say the same for SHA-256 or SHA-512.  While SHA-256
or SHA-512 may well be better, that has made me reluctant to switch to
a hash function that I understand less well.  However, I may well be
forced to overcome my reluctance, given the recent results on SHA1.

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Shai Halevi <[email-masked]>
Date: Mon, 21 Mar 2005 15:16:56 -0500

>>>(If anyone can explain why, I'd love to know.)
>>>
>>> I don't have a concrete example of what goes wrong, but this sounds
>>> plausible to me.  The definition of security for a PRF makes no 
>>> guarantees about the pseudorandomness of its output if the key to the
>>> PRF is made public, so using a PRF with a public key is a strange
>>> thing to do.
> 
> The thing that strikes me as odd about this reasoning is that, in any 
> case, the TCR hash function (TCRHF) key must eventually be made public. 
> Users are likely to generate the TCRHF key using a PRNG of some sort, 
> such as /dev/urandom. What does it matter if you publish the state of 
> your computer's internal PRNG after you have published its output? 
> (Assuming you aren't foolish enough to use that same state to generate 
> any further data you wish to keep secret.)

The short answer is that the proof of security just does not go through.
The reason is that potentially, once you know the seed you can do things
that you couldn't do before (e.g., find collisions). It does not sound
likely, but we cannot prove otherwise.

I know that this is a highly non-satisfying answer. If not pseudo
randomness, surly there is some other property that would ensure that
using the output of PRG(seed) is secure even when the attacker learns
the seed. Yet we don't really know what other properties to suggest
here, or how to to prove such a statement in any reasonable way.

-- Shai

p.s. This problem is not unique to the TCR application. There are 
several places where similar problems arise. For example, once you 
already know what message is encrypted inside the ciphertext C, why 
should it matter if you know also the randomness that was used to 
generate C? Yet there are quite a few places where our proofs brake down 
explicitly because of such reasons. Chalk it up to gaps in our current 
theory.