Please don't editorialize titles. This one broke the site guidelines badly.
Cherry-picking the detail you think is most important from an article is editorializing. Threads are sensitive to initial conditions and the title is the dominant initial condition, so this is a big deal. Being the first (or luckiest) user to submit an article doesn't confer any special right to frame it for everyone else. HN readers should make up their own minds about what parts of an article are important.
If you want to say what you think is important about an article, that's fine, but do so in the comments. Then your view will be on a level playing field with everyone else's: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
The test fails on my OpenWRT 19.07.03 router's Dropbear installation.
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)
 Have not read the paper thoroughly enough to determine if this is true for this technique
As for FPGAs - forgive my ignorance - but can they even handle that kind of load? In my head I just see them breaking-down under the sheer thermal load.
They worked for Bitcoin before miners switched to ASICS; I imagine they'd be fine in this application as well.
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.
Edit: someone already detected this: https://github.com/multiformats/website/pull/62
It's been done before. ;)
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 .
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:
But this is far from the only choice. Hashing algorithms are trendy right now, and there's plenty to choose from.
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.
SHA256, SHA512 and Blake* algorithms are suitable for secure checksums and HMACs, but not password hashing
It uses BLAKE2 internally
> I also see no benefit to that approach
- less primitives
- less memory usage
- no concern regarding cycles
Anyways, most people don't use high entropy passwords, so there's little point in arguing against this IMHO.
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.
xxhash (https://github.com/Cyan4973/xxHash) with 32/64 bit output. The latest version, xxh3, supports up to 128 bit output.
meow hash (https://github.com/cmuratori/meow_hash)
The recently released Blake3 which is designed to be cryptographically secure is very fast also (https://github.com/BLAKE3-team/BLAKE3)
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.
2, and my real objection:
$ md5sum /dev/null
$ seahashsum /dev/null
<stdin>:2:0: seahashsum: command not found
- Blake2b (~20% faster)
- SHA-384/192 and SHA-512/256 (~50% slower)
- SHA-256 (~100% slower)
- SHA3-224 and SHA3-256 (~150% slower)
So if speed is absolutely important to you, like you are hashing millions of messages a minute and you have profiled and the speed of the hash function is absolutely the most important thing, then link the Blake2 or more recently Blake3 libraries and get the extra speed AND you don't have to deal with all of the security vulnerabilities.
Or, if speed is modestly important to you but you need to use primitives that are available on every single computer you will ever encounter, use SHA-512 and then truncate it to 32 bytes. Or if you really need that 160-bit level truncate to 20 bytes. (Truncation is usually a good thing with hash functions, defending against something called length-extension attacks.)
Or if you want to be substantially safer than all of these options and you are not doing a lot of hashing, use SHA-3. Also the performance of the others (that are not BLAKE) is generally somewhat artificially enhanced by dedicated processor instructions which will almost surely also happen for BLAKE (as it is based on the ChaCha cipher which is reasonably well used) and SHA-3 (as it is the new US government standard). I can't off the top of my head speak to the CoffeeLake Core i7 architecture without digging up some research about what instructions it implements, but its SHA-1 is 25% faster than its MD5 which suggests some dedicated SHA-1 instructions, at least.
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.