8 ms·

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 mov

by joshuak 10y ago

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.

loeg 10y ago
Or SHA-512/256, which is the same length as SHA-256.
- Dylan16807 10y ago
  Yes, you absolutely want a truncated version of SHA2 if you're going to be upgrading.
  - loup-vaillant 10y ago
    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.
    - Dylan16807 10y ago
      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.
      - loup-vaillant 10y ago
        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.
runeks 10y ago
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.
- joshuak 10y ago
  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.
diggan 10y ago
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 https://github.com/multiformats/multihash
- SadWebDeveloper 10y ago
  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.
- dom0 10y ago
  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).
- niftich 10y ago
  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 http://web.cs.ucdavis.edu/~rogaway/papers/relates.pdf
dom0 10y ago
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.
base698 10y ago
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.
- OJFord 10y ago
  The CLI could always just truncate it to 256b (or fewer) when used interactively.
- Buttons840 10y ago
  96a is not the full hash in git currently. Why couldn't you also refer to the above hash as 96a as well?
  - base698 10y ago
    You could, I was just saying I run across a lot of people that don't know you can reference them that way.
- deleted 10y ago
  [deleted]
- npongratz 10y ago
  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-28628-8_18.pdf http://link.springer.com/content/pdf/10.1007%2F978-3-540-286...
  - jgrowl 10y ago
    Maybe we just need better tooling to help us compare hashes easier. Not exactly sure what that would look like though.
divbit 10y ago
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 .. ?
- divbit 10y ago
  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?)
- elwell 10y ago
  Isn't it a bad idea to assume uniform distribution of variance over the hash?
  - GauntletWizard 10y ago
    Apparently not bad enough that SHA512/256 isn't in the SHA2 family.
  - hueving 10y ago
    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.

by joshuak 10y ago

loeg 10y ago

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

Dylan16807 10y ago
Yes, you absolutely want a truncated version of SHA2 if you're going to be upgrading.
- loup-vaillant 10y ago
  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.
  - Dylan16807 10y ago
    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.
    - loup-vaillant 10y ago
      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.

runeks 10y ago

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.

joshuak 10y ago
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.

diggan 10y ago

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 https://github.com/multiformats/multihash

SadWebDeveloper 10y ago
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.
dom0 10y ago
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).
niftich 10y ago
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 http://web.cs.ucdavis.edu/~rogaway/papers/relates.pdf

dom0 10y ago

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.

base698 10y ago

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.

OJFord 10y ago
The CLI could always just truncate it to 256b (or fewer) when used interactively.
Buttons840 10y ago
96a is not the full hash in git currently. Why couldn't you also refer to the above hash as 96a as well?
- base698 10y ago
  You could, I was just saying I run across a lot of people that don't know you can reference them that way.
deleted 10y ago
[deleted]
npongratz 10y ago
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-28628-8_18.pdf http://link.springer.com/content/pdf/10.1007%2F978-3-540-286...
- jgrowl 10y ago
  Maybe we just need better tooling to help us compare hashes easier. Not exactly sure what that would look like though.

divbit 10y ago

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 .. ?

divbit 10y ago
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?)
elwell 10y ago
Isn't it a bad idea to assume uniform distribution of variance over the hash?
- GauntletWizard 10y ago
  Apparently not bad enough that SHA512/256 isn't in the SHA2 family.
- hueving 10y ago
  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.