You keep saying that here, and on Twitter, and people --- not just me --- keep telling you that if you're going to recommend a hash specifically to avoid length extension attacks, 512/256 accomplishes that without requiring the adoption of new hashing code.

I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256? We could call it SHA2.5: better than SHA-2, not quite SHA-3. Or SHA5: better than both!

Renaming SHA-2 512/256 sounds a lot easier than getting new hash code implemented in every library.

We should definitely rename it, because until yesterday I didn't know that "SHA-512/256" was an actual thing. I thought it was just shorthand referring to both SHA-512 and SHA-256.

Edit: this comment got 7 upvotes before the editing timeout, so I'm not the only one either.

Having read the article and the comments above yours, and being generally aware that there's some truncation thing related to SHA-256 and SHA-512 somewhere, it still took me until your comment to catch onto that.

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', 'shake_256']"

So - no reference to sha2_512/256 as a unique algorithm there either. Nothing in https://docs.python.org/3/library/hashlib.html either. So, the whole SHA-2 512/256 thing isn't that straightforward.

With that said, I would hope that anyone who was doing this for a real purpose would at least take 10 minutes to read the wikipedia page. And lots of useful information on crypto.stackexchange.com as well.

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

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.

NIST did specify a SHA-512/256 that has its own IV, like SHA-384.

Even SHA-224 has it's own IV, while it's internals are exactly the same as SHA-256

Touche!

> I really don't understand the argument that people can safely type "SHA-3" but not "SHA-2 512/256". Would it help if we renamed SHA-2 512/256?

The name is a serious problem. If you work with this stuff regularly enough to know the difference it might seem obvious, but that's not the case for many would-be implementors and bug-fixers.

The name makes communication problematic enough to not recommend usage.

No, it doesn't. SHA-2 is by an overwhelming margin the most popular hash used in cryptosystems today, and it is overwhelmingly used safely.

Seriously, if you care that much about the name, rename it; Even systems that use SHA-3 use HMAC (SHA-2 is perfectly safe, no matter what variant you use, in HMAC). Name the prefix MAC (an idiosyncratic construction) that uses SHA-2 something specific.

The SHA-3 advocates have already conceded this point. They don't call SHA-3's prefix MAC "prefix MAC"; they call it KMAC, which is a specific construction.

So all you have to accept is that there's SHA2MAC --- which, like KMAC, is not simply the hash function, but instead the optimal MAC construction built on the hash --- and then define it as the prefix MAC built from SHA2-512/256.

Reading your post I find myself understanding what you are saying... maybe. And that's my point. Communication is unclear.

It's hard enough to follow this topic for many people that want to keep updated. The fact that you have to spell out "please use SHA2-512/256, but not SHA2-512 and not SHA2-256" is mind-numbing.

"It's really SHA2-512/t where t has a value of 256 and that means that it's SHA2-512 truncated down which alleviates length extension attacks." Just typing that sentence gave me a headache and I have no real idea if it's right or not.

Adoption would be easy if communication was easy. As it is, it's a PITA to even have a short conversation on the subject.

I think you're confusing the SHA-2 hash core with a MAC derived from SHA-2. MACs and hashes aren't the same thing. You can build a MAC on a hash --- in fact, you can build a MAC on a hash that would be terribly insecure on its own, and some of those MACs are state-of-the art; see, for instance, all the polynomial MACs.

That's what I'm trying to articulate. Hashes aren't MACs.

This is partially my fault, for playing loose with SHA-2 512/256 vs "The Prefix MAC built on SHA-2 512/256".

Again: I think we should just call that SHA-2-MAC. It's an unambiguous name that couldn't mean anything other than "truncated SHA-2 512 used as a prefix MAC".

I think the BLAKE2 authors just choose to call it "keyed hashing" and telling people to use it as a MAC. Only somewhere in the paper where the construction is described there is an embedded clause "yes yes, that's prefix mac, hush" :)

I addressed that point in the post. Unless you replace all the implementations of SHA-2, the deed is done. People will choose SHA-256 and SHA-512 because that's what they've always known.

> without requiring the adoption of new hashing code

I should have made myself clearer: I recommend SHA-3 for new projects. I wouldn't recommend people to switch to SHA-3 if they are already using SHA-2.

This is a little like saying that if you told someone to use Rijndael they might instead use DES.

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!

I think you're reaching here.

I might be a bit. Although, I don't feel like it's too far from the kind of misuse we've pointed out with nonce re-use in AES-GCM or nonce re-use in DSA/ECDSA.

Anyway that was my point! Just wanted to write it up :)

Are your respective companies (yours and OP's) business competitors?

WAT. No, we just both like to argue on twitter and here :]

They are both professional consultants in this space.

Why not recommend SHA384 which AFAIK is exactly a truncated SHA512 without the "name collision" with SHA256? Or SHA224 which is the same from SHA256?

To maximize both performance and the number of truncated bits, which is the factor mitigating length extension.

> both performance

Surely SHA384 is no slower than SHA512/256 since both need to compute a SHA512 hash before truncation?

> and the number of truncated bits, which is the factor mitigating length extension.

Is there really a meaningful difference in mitigation between truncating 25% and 50% of the original hash?

> (especially for tree hashing, which makes K12 better than any other hash to hash big files).

I am aware that other modern hash functions like BLAKE2 (and maybe BLAKE/Skein?) support tree hashing, is there any reason why K12 would be better for that?

No not really. I cited BLAKE2bp or BLAKE2sp in the post.