Live data from Hacker News

SHA-1 collisions now cost $45k [pdf]

eprint.iacr.org

61–64 of 64 posts

Re: SHA-1 collisions now cost $45k [pdf]

#61
post #59

Earlier quoted context omitted.

Please justify why hashing a high entropy password should have a high cost. I can't see any benefit arising from this. If anything you lose entropy if you use something like pbkdf due to cycles.

Because it slows down anyone looking to crack/reverse the passwords? The only thing protecting your high entropy password is the cost of the hash. If you could run infinite attempts in 2 seconds then even your high entropy password would fail. Anyways, most people don't use high entropy passwords, so there's little point in arguing against this IMHO.

> Because it slows down anyone looking to crack/reverse the passwords?

Good luck brute-forcing through 2^256 passwords. The speed of the hash function should not matter.

If you still want a slow hash function though then just use more rounds.

> The only thing protecting your high entropy password is the cost of the hash

No, not really. It is the fact that the password is high entropy, combined with the preimage resistance of the hash.

> If you could run infinite attempts in 2 seconds then even your high entropy password would fail.

So would your pkdf.

Re: SHA-1 collisions now cost $45k [pdf]

#62

I understand not wanting to use SHA-1 now for security reasons, but is it still an OK practice to use it as a general hashing function for a uuid/data checksum?

> is it still an OK practice to use it as a general hashing function for a uuid/data checksum? No. If you don't care about collision resistance, use MD5. It's faster, it's smaller, and it makes it obvious to everyone than your software isn't supposed to rely on collision resistance.

No. MD5 is a cryptographic hash function. For the purposes stated one uses a non-cryptographic hash function, such as seahash. The difference is the latter is much faster but does not provide protection against an intentional collision.

Re: SHA-1 collisions now cost $45k [pdf]

#63
post #32

Not a crypto expert, how easy/hard it is with this (or other techniques) at the moment to generate a random file which matches a given SHA1 hash? Can have totally random bits lets say.

What's been done here is a chosen-prefix collision attack [1] where the attacker can produce two files that have the same hash. What you're asking about is a preimage attack [2] where one of the files is already created and the attacker can't influence it. The practical attack enabled here is mostly around digital signatures. An attacker could produce documents A and B that both have the same SHA-1. They can then get…

It should be noted that certain modern signature schemes (such as ed25519) are fine with just preimage resistance.

Re: SHA-1 collisions now cost $45k [pdf]

#64

Earlier quoted context omitted.

> is it still an OK practice to use it as a general hashing function for a uuid/data checksum? No. If you don't care about collision resistance, use MD5. It's faster, it's smaller, and it makes it obvious to everyone than your software isn't supposed to rely on collision resistance.

No. MD5 is a cryptographic hash function. For the purposes stated one uses a non-cryptographic hash function, such as seahash. The difference is the latter is much faster but does not provide protection against an intentional collision.

1: MD5 still provides preimage resistance (both first and second), which is sometimes useful.

2, and my real objection:

  $ md5sum /dev/null
  d41d8cd98f00b204e9800998ecf8427e  /dev/null
  $ seahashsum /dev/null
  :2:0: seahashsum: command not found
That said, my main point was don't use SHA-1, because if you actually need a half-broken hash function for something, MD5 has all the same properties (good and bad) for cheaper.
Post reply on HN