[tor-bugs] #8961 [Tor]: src/or/replaycache.c hashes entries with SHA-1

[Tor Bug Tracker & Wiki]

#8961: src/or/replaycache.c hashes entries with SHA-1
--------------------------+------------------------------------
 Reporter:  rransom       |          Owner:
     Type:  enhancement   |         Status:  needs_review
 Priority:  Medium        |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor           |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs, easy  |  Actual Points:
Parent ID:                |         Points:  small
  Sponsor:                |
--------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:4 gtank]:
 > Tried writing this in two ways; one less invasive and the other more so.
 The small one (https://github.com/gtank/tor/tree/8961-small) just calls
 openssl SHA512. The big one (https://github.com/gtank/tor/tree/8961-big)
 adds SHA512 support throughout src/common/crypto.c.

 Thanks for the patch, it looks good, but I'm not sure about the original
 approach suggested in the ticket:
 (I am sorry, I don't want you to feel like you wasted your time.)
 * why do 32-bit platforms get less protection?
 * why not switch to using digest256map_t? (I think it's new since this
 ticket was created)

 Then there's no truncation, no need to prepend a random value, and the
 patch is nice and small. (digestmaps already uses a random-keyed siphash
 internally, so an attacker would have to get an exact SHA256 match.)

 I'd also take a patch for SHA512 support throughout src/common/crypto.c as
 a feature in another ticket. I've created #17663 to track adding SHA512
 support. And I'll add some feedback there.

 Do you think you could write unit tests?

 > Neither prepends random bytes- I'm unclear if the attacks discussed in
 #4900 apply to cryptographic hashes. If they do, either of these could be
 easily modified to take advantage of the existing siphash key.

 Yes, the attacks do apply to cryptographic hashes, but I'm not sure if
 they're feasible at 160 bits:
 * the attacker knows the hash (SHA256 or SHA512)
 * they know that we only use the first 160 bits
 * they choose a 160-bit value to target for O(N) performance
 * they keep hashing random values, sending each one that truncates to that
 160-bit value to the victim

 Prepending a large enough random secret prevents this attack, because the
 attacker no longer knows the hashed output value.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8961#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online