12
$\begingroup$

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?

Improve this question
$\endgroup$
5
  • 2
    $\begingroup$ Simplicity, perhaps.. a standardized algorithm needs to be simple, have few configuration options so that it can't be "used wrong", and to minimize support and transition costs. Applications which want more can always use the full version.. it doesn't just disappear because NIST chose to make some changes. $\endgroup$
    – Thomas
    Aug 27, 2013 at 16:07
  • $\begingroup$ Well, I thought maybe that someone can come up with an argument for why this is a good idea for hardware implementations. But since most of the complexity is in Keccak-F[1600] and this function is simply resused for all combinations of capacity and output length, I don't really see how the restriction of 256 or 512 bits saves much complexity. $\endgroup$
    – sellibitze
    Aug 27, 2013 at 21:18
  • $\begingroup$ For most user a hash function is mostly defined by its output size. Allowing any capacity would bring a lot of confusion and endless debugging time to those users. A few good options is much better than a ton of excellent-for-my-usage-if-i-know-what-i-m-doing ones $\endgroup$
    – Alexandre Yamajako
    Aug 27, 2013 at 22:37
  • $\begingroup$ @AlexandreYamajako: This is about the internal working state size, not the output size. $\endgroup$
    – B-Con
    Aug 28, 2013 at 0:16
  • 2
    $\begingroup$ If you want to see what happens if you allow as many kinds of input and output take a look at the KBKDF specifications from NIST. Then take a look at their CAVP test vectors and the validated implementations. Great security, great flexibility, countless test vectors and no compatibility what so ever. Now if they had also standardized a few configurations, specified OID's... $\endgroup$
    – Maarten Bodewes ♦
    Aug 31, 2013 at 18:47

1 Answer 1

Reset to default
12
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thank you for pointing to section 6 of the Sakura paper. $\endgroup$
    – sellibitze
    Sep 3, 2013 at 13:13
  • $\begingroup$ I'm not convinced that supporting more capacities (if we restrict ourselves to multiples of 64 bits) has to mean "lots more code" especially if we're talking about software. $\endgroup$
    – sellibitze
    Sep 3, 2013 at 13:14
  • $\begingroup$ I wrote my sponge/absorb code that is compliant with any capacity/output length after I did a basic single capacity beta... it was substantially more code and much harder to debug and get correct, with most of it in the squeeze (absorb was 2 lines of code to change for my implementation). $\endgroup$
    – Richie Frame
    Sep 4, 2013 at 8:30

Your Answer

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

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