Earlier quoted context omitted.
It's not a unique and different algorithm. It is simply a truncated SHA-2 512 hash.
NIST did specify a SHA-512/256 that has its own IV, like SHA-384.
Touche!
Maybe we shouldn't skip SHA-3
101–110 of 112 posts
Re: Maybe we shouldn't skip SHA-3
#102Earlier quoted context omitted.
That's not necessarily a dangerous assertion. SHA-2 is theoretically immune to foreseeable improvements in computational power. If you use something like SHA-512, a birthday attack will require searching through approximately more candidates than there are atoms in the observable universe. You can't meaningfully improve this by scaling up inordinate amounts of computing power. If you can't rely on raw computational p…
Additionally, the primitives used in the SHA-2 core are well-enough understood and accepted that for SHA-2 to be broken, pretty much all the hashes are going to end up broken --- is how the rest of the logic would go. (This is, I think, JP Aumasson's argument.)
I always wonder when this pops up, are there cryptographers who don't think that. Not necessarily forever but within, say, 30 years.
Re: Maybe we shouldn't skip SHA-3
#103Earlier quoted context omitted.
That's not necessarily a dangerous assertion. SHA-2 is theoretically immune to foreseeable improvements in computational power. If you use something like SHA-512, a birthday attack will require searching through approximately more candidates than there are atoms in the observable universe. You can't meaningfully improve this by scaling up inordinate amounts of computing power. If you can't rely on raw computational p…
> "improvements in math might happen" is not reliable enough to calibrate forced obsolescence or regular updates Definitely: it doesn't make much sense to move away from a hash that doesn't seem in danger of being broken, just because it is old — a clever new attack can be found for a newer hash, too (or for both). Besides, usually there's a lapse of time between finding a major weakness and a practical collision. On…
True. But part of the question is whether to spend the engineering effort to make sure it's even possible to move away.
Re: Maybe we shouldn't skip SHA-3
#104Re: Maybe we shouldn't skip SHA-3
#105Earlier quoted context omitted.
This thread is the first time I was ever aware that "SHA-2 512/256" was actually a unique and different algorithm. I've always thought it was just the last 256 bits of SHA-512. Also, just looking at a reasonably recent version of Python 3.6: (dir(hashlib)) "'blake2b', 'blake2s', 'md5', 'new', 'pbkdf2_hmac', 'sha1', 'sha224', 'sha256', 'sha384', 'sha3_224', 'sha3_256', 'sha3_384', 'sha3_512', 'sha512', 'shake_128', 's…
It's not a unique and different algorithm. It is simply a truncated SHA-2 512 hash.
From: https://en.wikipedia.org/wiki/SHA-2
"In March 2012, the standard was updated in FIPS PUB 180-4, adding the hash functions SHA-512/224 and SHA-512/256, and describing a method for generating initial values for truncated versions of SHA-512. Additionally, a restriction on padding the input data prior to hash calculation was removed, allowing hash data to be calculated simultaneously with content generation, such as a real-time video or audio feed. Padding the final data block must still occur prior to hash output"
This sounds like more than just truncating SHA-2 512. Also, the various articles on stackexchange state that there is no way to truncate SHA-2 512 and conform to SHA-2 512/256.
Finally, https://eprint.iacr.org/2010/548.pdf sounds like they really wanted you to be able to distinguish SHA-512/256 from a truncated SHA-512:
"In order for users to be able to distinguish between a SHA-512 digest which has been truncated and a SHA512/256 digest, we also offer new initialization constants, analogous to those used in SHA-384."
Re: Maybe we shouldn't skip SHA-3
#106Earlier quoted context omitted.
It's not a unique and different algorithm. It is simply a truncated SHA-2 512 hash.
From: https://en.wikipedia.org/wiki/SHA-2 "In March 2012, the standard was updated in FIPS PUB 180-4, adding the hash functions SHA-512/224 and SHA-512/256, and describing a method for generating initial values for truncated versions of SHA-512. Additionally, a restriction on padding the input data prior to hash calculation was removed, allowing hash data to be calculated simultaneously with content generation, such…
It's SHA-512 with a different IV (which is why you can't derive a compliant 512/256 from 512 directly) with the leftmost 256 bits taken as output. The rest of that stuff applies to all the SHA-2 hashes, I think.
None of this is security-relevant, including the IVs. You would have morally the same system if you just chopped 32 bytes off a SHA-512 hash.
Re: Maybe we shouldn't skip SHA-3
#107Earlier quoted context omitted.
I really don't agree. Rijndael and DES are different algorithm. SHA-512/256 is a made-up algorithm that you need to be aware of. Again I'm talking about "misuse" here. SHA-2 is vulnerable to misuse even if SHA-512/256 is not.
> SHA-512/256 is a made-up algorithm It's a published FIPS.
didn't know that!
Re: Maybe we shouldn't skip SHA-3
#108Re: Maybe we shouldn't skip SHA-3
#109Earlier quoted context omitted.
What if the use case is not security sensitive, I just want to implement a distributed hash ring for example?
If the use case isn't security critical, and you know for a fact it won't become security critical later, and MD5 is convenient for whatever reason, then just use MD5. Pardon my frustration, but: Jesus Christ, people. Why do we need to sell everyone on the fancy new thing in a hypothetical situation where it is defined not to matter?
No No No. Then you add another dependency on MD5. And MD5 is a very slow, complex hash function. Use MurMur, City or any of a number of really fast, non secure hash functions instead.
Re: Maybe we shouldn't skip SHA-3
#110Earlier quoted context omitted.
Regarding MD5. I advice people from using MD5 in new designs even if it is for HMAC-MD5. Not because that construct is broken (which it isn't), but because we add yet another dependency on an algorithm we in general consider too weak to use. Do you agreee with that advice?
Definitely don't use MD5!
I totally hear you. ;-)