4

Looking at NIST SP 800-108 and NIST SP 800-132 it is not clear to me how to best use Keccak properties for PBKDF2. As in how to implement iteration counts and password stretching similar in goals of PBKDF2 but when underlying PRF is a sponge construction.

Clearly using SHA3 with HMAC construction in PBKDF2 is suboptimal. Given that PRF is needed and KMAC128 & KMAC256 are specified. It would make more sense for PRF to be defined as HMAC-SHA2 or KMAC.

But does the rest of PBKDF2 still holds true of how PRFs are chained based on the number of iteration counts and outputs XORed for KMAC? Or would something different should be done when using KMAC due to its absorption/squeezing properties?

Has anywhere password stretching been defined with iteration counts for hashes such as Keccak, Blake and similar? Those that do not need HMAC construction to create PRF, or does PBKDF2 simply holds true for them.

Dima
  • 161
  • 3

2 Answers2

2

Looking at NIST SP 800-108 and NIST SP 800-132 it is not clear to me how to best use Keccak properties for PBKDF2. As in how to implement iteration counts and password stretching similar in goals of PBKDF2 but when underlying PRF is a sponge construction.

The underlying construction is not that important as long as you're using a PRF. It could even be a MAC based on a cipher, although the larger output size of a hash is beneficial to security.

Clearly using SHA3 with HMAC construction in PBKDF2 is suboptimal. Given that PRF is needed and KMAC128 & KMAC256 are specified. It would make more sense for PRF to be defined as HMAC-SHA2 or KMAC.

There is a bit of overhead of using SHA-3 within a HMAC construction. However, the whole idea of a PBKDF is that it involves a work factor. As long as that work factor remains the same for the normal user and the adversary then the goal is reached. More modern functions also make sure that the calculation cannot be easily sped up using specialized hardware, FPGA's or GPU's though, for instance by using memory-hard functions.

Currently there isn't too much hardware out that significantly accelerates SHA-3, but the issue is that this is likely to come. So if you're now using X-iterations of the function then newer hardware - possibly used by an adversary - will probably be able to perform the same calculations much faster. It therefore makes much more sense to stick to SHA-2 for PBKDF2, or maybe switch to a more modern PBKDF.

But does the rest of PBKDF2 still holds true of how PRFs are chained based on the number of iteration counts and outputs XORed for KMAC? Or would something different should be done when using KMAC due to its absorption/squeezing properties?

The absorption / squeezing is an internal detail of cSHAKE used in KMAC. It really should not matter.

Has anywhere password stretching been defined with iteration counts for hashes such as Keccak, Blake and similar? Those that do not need HMAC construction to create PRF, or does PBKDF2 simply holds true for them.

Blake2 is the hash used by Argon2. There was a password hashing contest that was specifically held as PBKDF2 wasn't considered to meet the requirements expected of a modern password hash / PBKDF.

TL;DR

For the sake of compatibility I'd strongly recommend to use one of the SHA-2 algorithms for PBKDF2. They are still considered strong functions and the use of a sponge rather than a Merkle-Damgård hash doesn't make much of a difference. Please do not use MD5 or SHA-1 though, if just because they are deprecated as well as the limited number of output bits.

Although sponge with KMAC may be more efficient - once significant support is implemented - but efficiency is not really a requirement in an algorithm that is supposed to rely on a work-factor (i.e. the "stretching" part). At the current time future acceleration is a threat to that property.

If you want to use a more modern PBKDF then I'd recommend to go with Argon2 rather than focusing on the underlaying hash algorithm. The (also) memory hard scrypt could be used if Argon2 is not available. Balloon hashing has simplicity, side channel protections and security proof - in case you're more adventurous.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
1

PBKDF2 is defined as follows (single output case for simplicity): $$\text{PBDKF}^F(pw, salt, count) = x_0 \oplus x_1 \oplus \cdots \oplus x_{cout} $$

In the above, $x_i = F(pw, x_{i-1})$ and the starting point is $x_0 = F(pw, salt)$. In this description, PBKDF2 is fairly agnostic to the underlying "PRF" $F$ (unless the $F$ is broken). So, using KMAC should be straightforward.

IMO, one can argue KMAC is theoretically better than HMAC. The reason is that the assumption on $F$ is not that it's a PRF in the traditional sense. Passwords are short, and we can't realistically expect them to be chosen uniformly at random. Instead, most analyses of PBKDF2 view F as a random oracle (or, as NIST calls it, a "One-Way function"). Concretely, we typically assume that $F(pw, x)$ produces random inputs for any new pair $(pw, x)$. Though both HMAC and KMAC can be shown to have such behavior in the indifferentiability framework (under appropriate assumptions), it doesn't generally hold for HMAC when considering variable-length inputs (HMAC has key collisions). To be clear, this is not an attack on the intended usage of PBDKF2, so this point doesn't have a significant practical impact.

With the above said, if one is willing to consider non-standard construction, one should use memory-hard constructions as pointed out in the comments.

Marc Ilunga
  • 4,042
  • 1
  • 13
  • 24