12

I just read the presentation slides of John M. Kesley (from NIST) for his invited talk at CHES 2013 about SHA-3 and learned that NIST is going to standardize Keccak with a possibly modified padding scheme. Ok, so far so good. But what I don't understand is why they thought it was a good idea to limit the possible capacity values to 256 and 512 when an implementation could easily support just about any value for the capacity that is a multiple of the word length of 64 bits.

Why did they restrict SHA3 to have only two possible capacities?

sellibitze
  • 321
  • 1
  • 9

1 Answers1

12

2 main reasons:

  1. The 2 capacities match the collision resistance of SHA2 for 32-bit (C=256) and 64-bit (C=512) word sizes.
  2. Simplicity, having only 2 capacity/rate combinations means that it does not have to be chosen or calculated from the digest size.

I have implemented Keccak in software, and forcing only 2 capacities means a lot less code in the absorb/squeeze functions. The idea of only 2 capacities with those values was suggested by the designers of Keccak themselves in section 6.2 of their Sakura tree hashing proposal:

Sakura: a flexible coding for tree hashing

Keccak's SHA3 submission originally specified C=512 for a 256-bit hash and C=1024 for a 512-bit hash. The reduction in the slides means 2 things:

  1. Speed; it is 23% faster for 256-bit hashes and a whopping 89% faster for 512-bit hashes due to the corresponding rate changes
  2. Security; resistance against preimage and collision drops from $2^n$ to $2^{n/2}$, where n is the digest size in bits, this would make SHA3 weaker than SHA2, which has preimage resistance of $2^n$

Keep in mind that SHA3 has not even reached draft stage yet, and there are plenty of people who disagree with the chosen capacities, so it may very well change prior to FIPS 202.

Richie Frame
  • 13,278
  • 1
  • 26
  • 42