# How would Keccak attain a 512-bit security level?

I am well aware that the general consensus is that a hashing algorithm with a security of 512 bits is unnecessary, but I'm just curious about how that would be implemented for Keccak despite that.

According to SHA-3 block sizes / bitrate calculation?, the bitrate of the algorithm would be calculated by 1600 - 2c = r. However, with C being 1024, one would get a negative value, which I assume would mean the algorithm will not work for that capacity.

Am I wrong in my assumption? Are there any workarounds that would allow for a capacity this high?

Again, this is just a theoretical question to sate my curiosity. I am well aware that such a level of security is considered unnecessary.

• The rate and capacity are independent, all you would do is truncate fewer total bits from the state. Having 16 lanes exposed might be an issue if you decided to play with fire and hash passwords with keccak. – Q-Club Mar 13 '18 at 5:36
• @Q-Club so does that mean the bitrate is effectively arbitrary? Why is it calculated using the equations from the other question then? – Lev Knoblock Mar 13 '18 at 5:39
• Whoops, I ment the digest length is independent of the rate and capacity. – Q-Club Mar 13 '18 at 5:49
• Ah, thanks for pointing out the error in my question – Lev Knoblock Mar 13 '18 at 5:50
• – Richie Frame Mar 14 '18 at 12:27

For a ‘512-bit security level’ (which is (completely meaningless)^2, since a 256-bit security level is already past the threshold of meaning), it suffices to choose capacity 1024 and digest length 1024 to thwart all generic classical and quantum attacks limited to $$2^{512}$$ cost.