Re: [tor-dev] SHA-3 isn't looking so hot to me

["Zooko O'Whielacronx" <zooko@xxxxxxxxx>]

Here is the letter I wrote to the SHA-3 mailing list, followed by
replies from Jon Callas and John Kelsey.

-------
From: Zooko O'Whielacronx
	
Folks:

You might be interested in this discussion on the tor-dev mailing list
about a new crypto protocol for Tor:

https://lists.torproject.org/pipermail/tor-dev/2011-November/date.html

One of the issues brought up by Tor developer Nick Mathewson was
whether to switch from SHA-1 to SHA-2 or instead wait for SHA-3. I
argued that SHA-2 is better than SHA-3 (at least for a few years).

I feel slightly traitorous saying it, because I've enjoyed reading
this mailing list for years, and many of the SHA-3 candidates are
beautiful constructions, and I want them to be widely studied and
used, but there you have it: I can't think of good arguments for the
Tor developers to jump to SHA-3. Perhaps you can!

Regards,

Zooko
-------

-------
From: Jon Callas

Why do you feel traitorous saying it? In my opinion it's the right
decision (and frankly, having read the notes, some of the others are
sub-optimal), and I'm a co-author of a finalist.

Engineering is the art of applying science within constraints. Those
constraints include but are not limited to the laws of physics,
budgets, schedules, performance, and so on. The worst decision is no
decision.

If you are unhappy with SHA-1 for security reasons, then your first
choice should be using SHA-256. Your second choice should be SHA-512,
possibly in one of the narrow-width constructions that NIST recently
published. Those are the best-understood secure hash functions we
have.

SHA-3 candidates, no matter which ones they are are each and all
slightly less well-understood than SHA-2, for all the obvious reasons.

If you are unhappy with the above assessment for *performance*
reasons, well, that's a different kettle of fish entirely. Further
discussion is needed, but it's easier to find a performance metric and
select along it than there is to find a security metric. It can be
done, obviously, but the debate is a lot more entertaining.

The hardest thing of all, of course, is to try to minimax the two
considerations, security and performance. That debate would be really
entertaining.

All of this, however, presupposes that Tor can't reserve an algorithm
identifier for SHA-3 and design things so SHA-256 is used now and
SHA-3 when it's finally available. And yes, that's easier said than
done, but heck, that's what engineering is, too.

       Jon
-------

-------
From: John Kelsey

For whatever it's worth, if someone asked me the same question, I'd
give the same advice--go ahead and switch to SHA256 or SHA512, but
make sure you build algorithm identifiers and versioning into your
protocol, so that it's possible to change hash functions (and
everything else) when you need to.

SHA1 has a claimed collision attack (which looks like it should be
right, but has never been verified experimentally), and also has a
certain collision attack at 2^{80} work, so if you are worried about
collisions in your application, you should definitely switch, and I
think SHA2 is pretty much the only good choice right now.  Similarly,
if you're in a position to change hash functions now, but it will be a
big pain to do it in two or three years, switching to SHA2 makes good
sense.  On the other hand, if you're only using SHA1 with HMAC to do
MACing and key derivation and random number generation, there doesn't
appear to be any great urgency in switching over, as there are no
results I'm aware of that come anywhere close to really threatening
those applications.  There's no reason to keep SHA1 around in those
applications if you don't need to, but there is also no enormous
urgency switching over to SHA2 or SHA3 for HMAC.

Finally, if you're only worried about preimage and second preimage
resistance, SHA1 still seems okay.  But be careful assuming that you
don't care about collisions--there are a lot of weird and surprising
things you can do to hash functions if you can find intermediate
collisions.  For example, if a single colliding message is no big
deal, but a billion messages with the same hash is a disaster for your
application, it turns out you care very much about the difficulty of
finding one collision at a time in your Merkle-Damgaard hash function.
 It's much safer to just use hash functions whose cryptographic
strength and width makes collisions impractical to ever find--that is,
hash functions like SHA2 instead of SHA1.

--John
-------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev