5 ms·

I agree that it's a new design decision, but I think there is reasonable support for making it. Hash function history has pretty well demonstrated that most im

I agree that it's a new design decision, but I think there is reasonable support for making it. Hash function history has pretty well demonstrated that most implementers don't understand the difference between pre-image security, hash output length and collision resistance. And the security margin is far from eliminated entirely. Not only is there significant margin in the round function itself over the full number ofrounds, but the 256-bit security level provided by the proposed SHA-3-512 seems fairly substantial to me. I don't quite understand your MAC output length math. As far as I can tell, at least HMAC-SHA1 security could be achieved with SHA-3-512 truncated to 20 bytes of output. From what I understand of sponge functions, pre-image security is based on capacity (more specifically, half the capacity) and that truncated output up to the desired security level is valid. The Keccak page parameter calculator claims 160-bit security can be achieved with a capacity of 320 bits and 160 bits of output. But I will admit that changing the pre-image security level association with output length does seem like it could create some confusion among people who do understand the current hash security situation. To be honest, I would be OK with NIST making the capacity for both be 512 bits (or 576 as DJB suggested). SHA-3-512 performance doesn't suffer much, since it has the most to lose there, security levels are reasonable and implementation is simpler. I would still like a higher performing version of Keccak given that there is already little enough reason to switch to it, but the 512/576 universal capacity might be a reasonable compromise since it wouldn't make SHA-3-256 THAT much slower from NIST's proposed parameters.

marshray 13y ago
> SHA-3-512 truncated to 20 bytes of output At this point, your fellow software developers are pointing and laughing at you for "inventing your own cryptography". Your function doesn't come standard in any library. Every single 3rd party audit of your architecture raises a red flag about this and you have trouble finding any official documentation to back you up. (Ask me how I know about this :-) I'm not trying to say you don't know what you're doing or that that wouldn't meet the security properties, I'm just saying that the whole point of NIST defining these standards is to save us from having to come up with this kind of thing on our own. NIST actually does define truncated versions of SHA-2, e.g., SHA-2-512/256. But they specify a different IV so that the functions are distinct. > some confusion among people who do understand the current hash security situation Right. I totally agree that most of the time we should assume that collision resistance is the relevant figure, whether we can see the attack or not. But still, SHA-2-256 has has 256 bits of preimage resistance just like a 256 bit random oracle. But SHA-3-256 will have 128? Can we use SHA-3-256 to derive an AES-256 key?
- pbsd 13y ago
  Don't forget that NIST has mentioned they'll standardize variable-output-length SHA3: SHAKE512 with 20 byte output would be perfectly fine. They've also mentioned they might include MAC and AEAD standards, so I'm not convinced the situation is as bad as you make it.
  - marshray 13y ago
    OK so NIST-SHAKE512-[0 <= bit < 256] is basically what was proposed as round 3 Keccak-256. But it's a) unwieldy to specify, and b) reveals the output of NIST-SHAKE512-[0 <= bit < 128] unlike other truncated hash standards. Note: I am definitely not saying this is the end of the world.

marshray 13y ago

> SHA-3-512 truncated to 20 bytes of output At this point, your fellow software developers are pointing and laughing at you for "inventing your own cryptography". Your function doesn't come standard in any library. Every single 3rd party audit of your architecture raises a red flag about this and you have trouble finding any official documentation to back you up. (Ask me how I know about this :-) I'm not trying to say you don't know what you're doing or that that wouldn't meet the security properties, I'm just saying that the whole point of NIST defining these standards is to save us from having to come up with this kind of thing on our own. NIST actually does define truncated versions of SHA-2, e.g., SHA-2-512/256. But they specify a different IV so that the functions are distinct. > some confusion among people who do understand the current hash security situation Right. I totally agree that most of the time we should assume that collision resistance is the relevant figure, whether we can see the attack or not. But still, SHA-2-256 has has 256 bits of preimage resistance just like a 256 bit random oracle. But SHA-3-256 will have 128? Can we use SHA-3-256 to derive an AES-256 key?

pbsd 13y ago
Don't forget that NIST has mentioned they'll standardize variable-output-length SHA3: SHAKE512 with 20 byte output would be perfectly fine. They've also mentioned they might include MAC and AEAD standards, so I'm not convinced the situation is as bad as you make it.
- marshray 13y ago
  OK so NIST-SHAKE512-[0 <= bit < 256] is basically what was proposed as round 3 Keccak-256. But it's a) unwieldy to specify, and b) reveals the output of NIST-SHAKE512-[0 <= bit < 128] unlike other truncated hash standards. Note: I am definitely not saying this is the end of the world.