How would Keccak attain a 512-bit security level?

Question

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.

Answer 1

The highest capacity possible is 1599, which means you repeat the permutation for every bit you enter into the state.

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.

The SHA-3 parameters for the fixed-length functions SHA3-256 etc. were overdesigned partly out of paranoia and partly for political reasons. The XOFs SHAKE128 and SHAKE256 were more reasonably designed to give a 128- or 256-bit security level, respectively, assuming adequate output length; if ‘SHAKE512’ existed it would use capacity 1024.