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.
SHA-1 collisions now cost $45k [pdf]
21–30 of 64 posts
Re: SHA-1 collisions now cost $45k [pdf]
#22How safe is SHA-256 now? Or Is SHA-512 needed in the near future?
Well, there's already a SHA-512.
But none of the SHA family of hashes have ever been recommended for passwords, not because they are weak, but because they are too fast.
For other purposes, the logical successor to SHA-256/512 is SHA-3:
https://en.wikipedia.org/wiki/SHA-3
But this is far from the only choice. Hashing algorithms are trendy right now, and there's plenty to choose from.
Re: SHA-1 collisions now cost $45k [pdf]
#23Is git fixed yet?
Re: SHA-1 collisions now cost $45k [pdf]
#24Earlier quoted context omitted.
It would scale linearly right? Double the amount of computing thrown at it, you'd half the time on average. Or am I mistaken?
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).
[deleted]
Re: SHA-1 collisions now cost $45k [pdf]
#25How safe is SHA-256 now? Or Is SHA-512 needed in the near future?
Well, there's already a SHA-512. But none of the SHA family of hashes have ever been recommended for passwords, not because they are weak, but because they are too fast. For other purposes, the logical successor to SHA-256/512 is SHA-3: https://en.wikipedia.org/wiki/SHA-3 But this is far from the only choice. Hashing algorithms are trendy right now, and there's plenty to choose from.
I am not sure why you mentioned passwords. Collision attacks do not affect the use of hash functions for password hashing.
Re: SHA-1 collisions now cost $45k [pdf]
#26Earlier quoted context omitted.
It would scale linearly right? Double the amount of computing thrown at it, you'd half the time on average. Or am I mistaken?
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 collisions to exploit various technologies that didn't stop trusting MD5 in a timely fashion, but it wasn't something they did a lot just one collision here or there as necessary. e.g. https://en.wikipedia.org/wiki/Flame_(malware)
Re: SHA-1 collisions now cost $45k [pdf]
#27How safe is SHA-256 now? Or Is SHA-512 needed in the near future?
Safe enough, but why not use a modern hash function instead?
Re: SHA-1 collisions now cost $45k [pdf]
#28Not 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.
This is not a preimage attack.
Re: SHA-1 collisions now cost $45k [pdf]
#29One of the best things to come out of protocol labs is https://multiformats.io/ Really simple mechanisms for things like identifying the hash algorithm and gives you a programmatic way of supporting new hash algorithms without breaking or changing anything that depends on the old.
The PHC string format https://github.com/P-H-C/phc-string-format/blob/master/phc-s... (used by stuff like Rust's LibreAuth/BoringAuth) is a less fancy but probably better-suited-to-passwords solution, because it can indicate salt values and additional parameters.
Re: SHA-1 collisions now cost $45k [pdf]
#30How 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.
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