31–40 of 64 posts
One 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.
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.
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 someone to sign document A (which really is signing the SHA-1 of document A), then use the signature with document B and make it look like they have a document B signed with a valid signature.
As an example, if document A is a regular SSL certificate request, and document B is a "CA certificate", the attacker can trick a real CA into signing a rogue CA into existence, which can then sign its own certificates that will be trusted by every browser. This has already happened with MD5 in 2008 [3].
[1] https://en.wikipedia.org/wiki/Collision_attack
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.
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
> argon2
It uses BLAKE2 internally
Is git fixed yet?
https://github.com/git/git/commit/28dc98e343ca4eb370a29ceec4...
How 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.
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.
It also cost 2 months (FTA)... So the ever returning question is : how long does it take when NSA/military/government-levle funding is applied ?
How 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?
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…
It also cost 2 months (FTA)... So the ever returning question is : how long does it take when NSA/military/government-levle funding is applied ?
It would scale linearly right? Double the amount of computing thrown at it, you'd half the time on average. Or am I mistaken?
[0] Have not read the paper thoroughly enough to determine if this is true for this technique