What is going on with NIST’s SHA-3?
1–10 of 50 posts
Re: What is going on with NIST’s SHA-3?
#2Basically, NIST seems to be reasoning that because Keccack's sponge construction has no internal resistance to meet-in-the-middle attacks, the collision and preimage resistances are the same.
An upper bound on the security of Keccack is set by the expression
c + r = 1600.
'r' is the rate (bits per expensive f() function invocation) at which the message input can be processed.
Due to some basic and well-understood attacks, we know that Keccak cannot be more secure than c/2 bits.
NIST was planning to assign SHA-3-256 and SHA-3-512 having 128 and 256 bits of security respectively. On one hand, this sounds like a nice conservative overall security rating based on the (lower) collision resistance.
But NIST plans to re-tune these internal constants downwards, setting c to 256 or 512. Whereas the competition final round submission specified c = 448 and 1024 bits. The resulting speed boost is 24% and 89%.
I don't think anyone should presume ill intent here on the part of NIST. But it sure doesn't seem like a good time to propose cutting security margins down to the limit of publicly-known attacks. The idea of a hash function which outputs 256 bits having only 128 bits of preimage resistance is unprecedented.
Re: What is going on with NIST’s SHA-3?
#3Also, this setting does not address the security of MAC constructions based on SHA-3.
For instance, HMAC over SHA-2-256 or SHA-2-512/256 with a 256-bit key is expected to attain 256-bit security (i.e. the MAC size equals the security level).
Yet SHA-3-256 would not reach anything above 128-bit security, even though the MAC is 256 bits long; to attain 256-bit security one would have to scale the MAC size up to 512 bits instead.
Re: What is going on with NIST’s SHA-3?
#4Also, this setting does not address the security of MAC constructions based on SHA-3. For instance, HMAC over SHA-2-256 or SHA-2-512/256 with a 256-bit key is expected to attain 256-bit security (i.e. the MAC size equals the security level). Yet SHA-3-256 would not reach anything above 128-bit security, even though the MAC is 256 bits long; to attain 256-bit security one would have to scale the MAC size up to 512 bit…
[deleted]
Re: What is going on with NIST’s SHA-3?
#5I think this is an excellent example for the application of duck typing.
Re: What is going on with NIST’s SHA-3?
#6Also, this setting does not address the security of MAC constructions based on SHA-3. For instance, HMAC over SHA-2-256 or SHA-2-512/256 with a 256-bit key is expected to attain 256-bit security (i.e. the MAC size equals the security level). Yet SHA-3-256 would not reach anything above 128-bit security, even though the MAC is 256 bits long; to attain 256-bit security one would have to scale the MAC size up to 512 bit…
[deleted]
[deleted]
Re: What is going on with NIST’s SHA-3?
#7Also, this setting does not address the security of MAC constructions based on SHA-3. For instance, HMAC over SHA-2-256 or SHA-2-512/256 with a 256-bit key is expected to attain 256-bit security (i.e. the MAC size equals the security level). Yet SHA-3-256 would not reach anything above 128-bit security, even though the MAC is 256 bits long; to attain 256-bit security one would have to scale the MAC size up to 512 bit…
[deleted]
And since we're at this, perhaps you meant c _between_ 448 and 1024, according to the sec level?
Re: What is going on with NIST’s SHA-3?
#8Earlier quoted context omitted.
[deleted]
And since we're at this, perhaps you meant c _between_ 448 and 1024, according to the sec level?
Yeah, Keccak-224 specified c=448. I was trying to simplify things by sticking to Keccak at 256 and 512 bit fixed output lengths, which specified c=512 and c=1024 respectively.
Re: What is going on with NIST’s SHA-3?
#9Also, this setting does not address the security of MAC constructions based on SHA-3. For instance, HMAC over SHA-2-256 or SHA-2-512/256 with a 256-bit key is expected to attain 256-bit security (i.e. the MAC size equals the security level). Yet SHA-3-256 would not reach anything above 128-bit security, even though the MAC is 256 bits long; to attain 256-bit security one would have to scale the MAC size up to 512 bit…
I think you would be safe using SHA-3-512 and truncating to 256 bits but that is a rather ridiculous way to set up a cryptographic primitive.
Re: What is going on with NIST’s SHA-3?
#10Basically, NIST seems to be reasoning that because Keccack's sponge construction has no internal resistance to meet-in-the-middle attacks, the collision and preimage resistances are the same. An upper bound on the security of Keccack is set by the expression c + r = 1600. 'c' represents the internal bandwidth of the hash that is not directly controllable by an attacker. 'r' is the rate (bits per expensive f() functio…
Thanks! This was much clearer than the blog post.