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.

  • $\begingroup$ 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. $\endgroup$
    – Q-Club
    Commented Mar 13, 2018 at 5:36
  • $\begingroup$ @Q-Club so does that mean the bitrate is effectively arbitrary? Why is it calculated using the equations from the other question then? $\endgroup$ Commented Mar 13, 2018 at 5:39
  • $\begingroup$ Whoops, I ment the digest length is independent of the rate and capacity. $\endgroup$
    – Q-Club
    Commented Mar 13, 2018 at 5:49
  • $\begingroup$ Ah, thanks for pointing out the error in my question $\endgroup$ Commented Mar 13, 2018 at 5:50
  • $\begingroup$ related crypto.stackexchange.com/questions/18695/… $\endgroup$ Commented Mar 14, 2018 at 12:27

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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.