Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eprint.iacr.org

Post reply on HN
Print view View original

41–50 of 64 posts

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

#41

Post by rhacker »

tialaramex wrote: post #26
finnh wrote: post #15

Earlier quoted context omitted.

And of course double the compute for half the time = same cost (more or less). I would imagine the NSA has sunk enough into hardware to do this fairly cheaply per-pass, and very quickly (hours not weeks).

Cloud computing makes this true for everybody else too now, at least within a practical range. Now I can easily afford a multi-million dollar distributed compute facility... for a few hours, rented from Amazon. I'd be surprised if the NSA has a clear purpose for bulk colliding SHA-1. It's a pretty niche thing to want to do even compared to say, "cracking" DES. For MD5 we know such government agencies made some collis…

I do think it's amazing that we can now script out a million dollar data center, build up, tear down for just an hour of use (and just a fraction of the cost). And that's available to ordinary people (with a little budget obviously). Compare what we had 20 years ago. Mind blown.

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

#42

Post by zenhack »

easterncalculus wrote: post #21
ww520 wrote: post #20

How safe is SHA-256 now? Or Is SHA-512 needed in the near future?

SHA-256 is still secure for plenty of applications, but for awhile it's been regarded as a suboptimal choice for password hashing. SHA512 is probably overkill.

"for a while" suggests that this was ever a recommended choice, which is not the case. As others have pointed out, for password hashing you want a specialized algorithm, not a general purpose cryptographic hash function. This is true regardless of whether the hash function is "compromised;" it just wasn't designed for that application in the first place.

Algorithms designed for password hashing are intentionally both compute and memory intensive, to make guessing slower, whereas general cryptographic hash functions are by contrast intended to be fast, as most applications will want that. The idea is that password hashing algorithms should be fast enough to keep up with a human and no faster; if you already know he password the performance is not a hindrance but if you have to guess it makes doing so impractical.

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

#43

Post by easterncalculus »

zenhack wrote: post #42
easterncalculus wrote: post #21

Earlier quoted context omitted.

SHA-256 is still secure for plenty of applications, but for awhile it's been regarded as a suboptimal choice for password hashing. SHA512 is probably overkill.

"for a while" suggests that this was ever a recommended choice, which is not the case. As others have pointed out, for password hashing you want a specialized algorithm, not a general purpose cryptographic hash function. This is true regardless of whether the hash function is "compromised;" it just wasn't designed for that application in the first place. Algorithms designed for password hashing are intentionally both…

That's a fair point, I didn't want to come off like it was ever a great choice. I definitely would argue that people are more aware now than they used to be, so thanks for clarifying that.

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

#44

Post by willcipriano »

dependenttypes wrote: post #33
eadan wrote: post #30

Earlier quoted context omitted.

Not only sub-optimal, but unsuitable. Use algorithms specifically designed for password hashing: argon2 / scrypt etc. SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing

I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally

If you have two solutions and the first solution requires humans behave in a certain manner (getting them to use high entropy passwords) and the second does not. The second is more secure.

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

#45

Post by 0x0 »

dependenttypes wrote: post #33
eadan wrote: post #30

Earlier quoted context omitted.

Not only sub-optimal, but unsuitable. Use algorithms specifically designed for password hashing: argon2 / scrypt etc. SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing

I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally

Secure checksums should have high performance. Password hashing should have low performance (ie high cost).

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

#47

Post by AlexanderDhoore »

dokument wrote: post #46

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?

Are you protecting against random accidental data corruption? Or malicious attackers?

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

#48

Post by hinkley »

AlexanderDhoore wrote: post #47
dokument wrote: post #46

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?

Are you protecting against random accidental data corruption? Or malicious attackers?

Everyone is protecting against accidental data corruption, until someone figures out how to turn it into an attack.

Even when you ask people "is there any universe in which this could be used as an attack?" most people will reflexively say "no, of course not."

Most of us are wrong, which is why you have professional pen testers.

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

#49

Post by dependenttypes »

0x0 wrote: post #45
dependenttypes wrote: post #33

Earlier quoted context omitted.

I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally

Secure checksums should have high performance. Password hashing should have low performance (ie high cost).

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.

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

#50

Post by dependenttypes »

willcipriano wrote: post #44
dependenttypes wrote: post #33

Earlier quoted context omitted.

I disagree, I would argue that they are optimal for passwords with sufficient entropy (which includes passwords generated by a password manager) > argon2 It uses BLAKE2 internally

If you have two solutions and the first solution requires humans behave in a certain manner (getting them to use high entropy passwords) and the second does not. The second is more secure.

I do not see how this is relevant to what I said.
Post reply on HN