Hacker News Reader

Comment by joshuak | Hacker News Reader

Peter suggests that everyone using SHA-1 should move to SHA-256. That's a reasonable suggestion, but I say as long as you're making hashing changes why not move to SHA-512.

Remember, it's also in the FIPS SHA-2 standard and faster on 64bit CPUs then SHA-256. It's only 64 bytes long, surly that's not too much to handle.

Edit: Goggle also suggests SHA-256, so perhaps Peter was simply seconding the recommendation. I suggest SHA-512 is the better recommendation.

View on HN

Instead of just migrating everything to a new hashing function when something gets bad, why not migrate to something that would be future-proof and easy to switch out? Multihash[0] is one solution, where a hash contains information about what hash-function was used when generating the hash, so you can have the same input, multiple hashes.

- [0] https://github.com/multiformats/multihash

Multihash is nice, but it solves exactly two out of many problems with migrating to a new hash.

First, it carries the information of which hash function was used to produce the digest "in-band", so that this information does not need to be obtained out-of-band, or from a different input, or inferred from context.

Second, because it carries this information inside one data item, it essentially domain-segregates the information space of the digest by hash function, which ensures that two digests generated by two different hash functions never collide into the same value. While this property seems very useful, in truth this can only happen if the two different hash functions in question generate digests of the same length, and because the hash functions are different, you can't mount a collision attack, so you must work backwards from one of the outputs to try to break the other [1].

This then shows that the hard part about "migrating hashes" isn't usually the data structures, but rather the policies and practices on how you affect access or treatment of data items identified by or checksummed by the now-insecure hash; whether you have enough data and knowledge contained within the closed system that seamless migration is possible internally; how you communicate changes in content-addressing to users such that they can evaluate the trust and risks (similar to "seamlessly" upgrading HTTP to HTTPS), etc.

[1] I'm not a crypto expert so I'll avoid commenting in precise, technical terms [2] of which exact attack this would entail.

[2] http://web.cs.ucdavis.edu/~rogaway/papers/relates.pdf

This makes the output length rather odd (not even divisible by 4 bytes), although that wouldn't matter much in non-performance critical applications. Also to keep in mind; when using hashes as a key for something (file name, hash table), here you'll need to take bits from the end, not the beginning, when splitting it up (eg. for using multiple directory levels).

Didn't know about this spec/format (i know they called a protocol, m not so sure it can be accurately called that way) seems cool until you have to realize that you must support all hashes or at least a handful of that in your app which is convenient from the developer POV but wasteful from the database-administrator because you must either future-proof that column size or drop performance altogether and start using "document-db" for authentication which is kinda odd.

IMHO you should not "future-proof" password hashes, collision attacks for passwords are more difficult to achieve than many people realize. What you should as a developer do, is stop using the hash and only migrate systems that actually required in a case by case basis.

Depending on the application the overhead of 512 bits vs 256 bits is significant. In these applications SHA-512-256 and BLAKE2b-256 are my go-to recommendations. I don't recommend SHA-3; it's design is obviously considered very solid, but it's performance characteristics make it uninteresting for software compared to both SHA-2 and BLAKE2.

I wouldn't recommend using SHA-2-512 for added security. Choosing SHA-3-256 would make more sense, as more knowledge has gone into the construction of SHA-3 than SHA-2, and the double bit length doesn't buy you anything if the fundamental construction is broken.

The primary design purpose of SHA-3 was not to replace SHA-2 with something 'better' it was to provide an alternate approach for hashing such that if one approach to hashing is compromised there is a completely different approach to hashing that is still viable.

There are good reasons to use SHA-3, but one should not consider using SHA-3 on the grounds that it is known to be a better hashing algorithm then SHA-2. It is not. In fact, SHA-2 has a much greater level of confidence due to it's age.

Or SHA-512/256, which is the same length as SHA-256.

Yes, you absolutely want a truncated version of SHA2 if you're going to be upgrading.

Probably not. There's SHA-3 (though reputedly slow), and my favourite, Blake2b.

I've implemented both SHA-256 and SHA-512, and seen the more modern Blake2 in detail: Blake2 is not more complex, it's fast, and for now it's solid. I expect it to stay secure for a long time, given its Chacha heritage.

I meant that you definitely want the truncation, not whether you pick SHA2 or not. There are other choices for sure that are also immune to length-extension.

I love Blake2b's keyed mode (or the other modern hashes for that matter): now the easy way to do a hash based MAC is also the right way.

96a2dff2ba1aceed1994fddd9adc276556c789c52d3e5f8a1721703a461d41ab4ddd9563075e8adda6382a8c9d52be78ae07eec77dcfba58978ea87290a9028f

SO BIG. For git, most people don't realize in most cases if the repo isn't giant you can use just 96a as a shortcut. I imagine people would be turned off by the sheer size.

If I were eyeballing two hashes to make sure they were equal, I'd worry about my ability to see near collisions (similar to [0]) the longer the hashes were. My eyes just start skipping ahead at some point, and would probably miss different-but-similar-looking characters in the middle.

But I think SHA-512 is resistant to near-collisions (sorry, I don't have a citation), and besides, one would probably best compare hashes using a script one understands.

[0] http://link.springer.com/content/pdf/10.1007%2F978-3-540-286...

>I think SHA-512 is resistant to near-collisions

All good hash functions have an even distribution, and are therefore resistant to near-collisions. Hash tables for example require this property to work properly.

Maybe we just need better tooling to help us compare hashes easier. Not exactly sure what that would look like though.

Color the character boxes and display in two adjacent lines.

96a is not the full hash in git currently. Why couldn't you also refer to the above hash as 96a as well?

You could, I was just saying I run across a lot of people that don't know you can reference them that way.

KFyFwOkYdQatN3ZVjB16K3aY4KoydUr54rgfux33PuliXjqhykKkCjw is quite a bit nicer, I think, albeit case-sensitive.

s2rn74v2dlho2gmu7xozvxbhmvlmpcoffu7f7cqxefydurq5igvu3xmvmmdv5cw5uy4cvde5kk7hrlqh53dx3t52lcly5kdsscuqfdy is at least not case-sensitive.

The CLI could always just truncate it to 256b (or fewer) when used interactively.

Take the first 32 bytes of Sha512 if the extra bytes isare too annoying. This also gives you an extra 32 bytes to use for something like .. ?

There is a nice clean implementation in tweetnacl - while we are at it, commits could be signed with eddsa (or xeddsa/vxeddsa, though I don't know if those have compact libraries?)

Isn't it a bad idea to assume uniform distribution of variance over the hash?

No, one of the characteristics of a cryptographic hash function is that output should be completely unpredictable based on input. So the probability that the low order bits will change vs the high order bits should be exactly the same given any arbitrary inputs.

Apparently not bad enough that SHA512/256 isn't in the SHA2 family.

Reply on news.ycombinator.com