SHA3 status and PBKDF2-HMAC-SHA3 test vectors

Question

Since SHA-3 seems to be an already known function (Keccak as the finalist of NIST hash function competition) I have several questions related to this topic:

1. NIST site says that NIST is closed due to a lapse in government funding. Is there any chance that SHA-3 will ever be finally accepted?
2. BouncyCastle library has an implementation of SHA-3 which digest results are the same as examples posted in wikipedia article (I tested this). Since the final standard is not approved, can this be trusted? Wikipedia says this is likely to be changed but how can it change as the final algorithm does not seem to be a subject to change (or else it would be another algorithm).
3. Here someone noted that usage of PBKDF2 with SHA-3 for key strengthening and password hashing should be avoided. But I cannot understand why? (how can it give attacker an advantage if the algorithm is not fast?)
4. I could not find test vectors anywhere to test my implementation of PBKDF2-HMAC-SHA3 in scala based on BouncyCastle java api. I can post my test spec with some results. But first can anybody post any/spec test vectors?

Here is my implementation in scala:

package my.crypto

import org.bouncycastle.crypto.digests.SHA3Digest
import org.bouncycastle.crypto.generators.PKCS5S2ParametersGenerator
import org.bouncycastle.crypto.PBEParametersGenerator
import org.bouncycastle.crypto.params.KeyParameter

object PBKDF2WithHmacSHA3 {

  def apply(password: String, salt: Array[Byte], iterations: Int = 65536, keyLen: Int = 256): Array[Byte] = {
    val generator = new PKCS5S2ParametersGenerator(new SHA3Digest(256))
    generator.init(
      PBEParametersGenerator.PKCS5PasswordToUTF8Bytes(password.toCharArray),
      salt,
      iterations
    )
    val key = generator.generateDerivedMacParameters(keyLen).asInstanceOf[KeyParameter]
    key.getKey
  }
}

One questionable thing for me is new SHA3Digest(256), the 256 bit length in the constructor, should it be same as provided key length or some fixed one as I did? I decided to use a fixed length because only some fixed values can be used and object API user can provide any value as key length parameter, but most of uncommon ones would result in exception thrown from inside SHA3Digest constructor. Also the default value seem to be 288 (when no key length is provided) which looks strange.

Thanks in advance!

Erythro

The U.S. government shut-down is a temporary situation. The ultimate resolution of something like the adoption of a new secure hash algorithm will not be affected by it. At worst it could conceivably be delayed a week or two, assuming it is destined for acceptance. – Houseleek

(as a sidenote: that someone was me) – Charie

If you can find three (or more) libraries with Final Round Keccak implementations, and possibly help with coding the interface if they're in languages you know, I'd be delighted to generate and publish PBKDF2-HMAC-FinalRoundKeccak-xxx test vectors. The test vectors I usually use and some sample libraries are at my fledgling github site - note the varying licenses, of course. I'm asking for three because if all three agree (and pass dependency test vectors, i.e. known FRKeccak outputs, I assume it's good. – Stagnate

Answer 1

1. Shutdown is temporary. SHA-3 will most likely be standardized at some point in 2014.

2. No, those values are probably for Final Round Keccak, not for SHA-3. There is no SHA-3 spec yet and it's quite likely that SHA-3 will be tweaked before standardization.

   => it's impossible to implement SHA-3 now, you can only implement Keccak.

3. Password hashes should be as expensive as possible for the attacker. The attacker uses different hardware from the defender, at minimum a GPU, but possible even custom chips.

   The defender has a limited time budged for a hash (e.g. 100ms) and wants a function that's as expensive as possible for the attacker given that constraint. This means that custom hardware shouldn't gain a big advantage over a standard computer. So it's preferable to use a software friendly hash, but Keccak is relatively hardware friendly.

   SHA-1 and SHA-2 are decent in hardware as well, so in practice the difference is small compared to the advantage other password hashes have over PBKDF2-HMAC-SHA-x. If you care about security instead of standard conformance, I recommend scrypt.

Charie

Hi, @CodesInChaos. Thanks for the great answer! Glad you found your quote here =). – Erythro

After reading wikipedia article about scrypt it seems like scrypt is a better option. And the article partly explains same thing as you did for #3. And it is included in BouncyCastle as well. Do you think it's good for using as key-derivation function for AES-256 with some salt and with some iv? – Erythro

Another question is: which are better solutions to use for hashing and message authentication - SHA-3 and HMAC-SHA-3 or SHA-256 and HMAC-SHA-256? Or maybe you can also recommend something stronger (since I care about security much more instead of standard conformance)? – Erythro

1) scrypt is a fine choice for that. One minor weakness is that it might be susceptible to cache timing attacks in cases where the attacker knows the salt. You should also consider using native code for this, you'll be able to use significantly higher work factors. 2) All of those are fine as MAC. Even HMAC-MD5 hasn't been broken (Still I wouldn't recommend it). 3) SHA-3 in duplex mode has the advantage that it can encrypt and MAC at the same time. As an alternative you can consider authenticated modes, like AES-GCM or XSalsa20Poly1305. – Charie