SHA3​​状态和PBKDF2-HMAC-SHA3测试向量

Question

由于SHA-3似乎是一个已知的函数（Keccak作为NIST哈希函数竞赛的决赛选手），我有几个与此主题相关的问题：

1. NIST site说NIST因政府资金失效而关闭。是否有机会最终接受SHA-3？
2. BouncyCastle库具有SHA-3的实现，其摘要结果与wikipedia article中发布的示例相同（我对此进行了测试）。由于最终标准未获批准，这可以信任吗？维基百科说这可能会改变，但它如何改变，因为最终的算法似乎不是一个改变的主题（否则它将是另一种算法）。
3. Here有人指出应该避免使用带有SHA-3的PBKDF2进行密钥加强和密码散列。但我不明白为什么？ （如果算法不快，怎么能给攻击者一个优势？）
4. 我无法在任何地方找到测试向量来测试我在基于BouncyCastle java api的scala中的PBKDF2 - HMAC-SHA3的实现。我可以用一些结果发布我的测试规范。但首先可以发布任何/ spec测试向量吗？

这是我在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
  }
}

对我来说，有一个值得怀疑的问题是new SHA3Digest(256)，构造函数中的256位长度，它应该与提供的密钥长度相同，还是像我一样固定一个？我决定使用固定长度，因为只能使用一些固定值，并且对象API用户可以提供任何值作为密钥长度参数，但大多数不常见的将导致从SHA3Digest构造函数内部抛出异常。此外，默认值似乎是288（当没有提供密钥长度时），看起来很奇怪。

提前致谢！

Answer 1

1. 关机是暂时的。 SHA-3很可能在2014年的某个时候被标准化。

2. 不，这些值可能是针对Final Round Keccak，而不是针对SHA-3。目前还没有SHA-3规范，很可能在标准化之前调整SHA-3。

   =＆GT;现在不可能实现SHA-3，你只能实现Keccak。

3. 攻击者的密码哈希值应尽可能昂贵。攻击者使用与防御者不同的硬件，至少是GPU，但甚至可以定制芯片。

   防御者有一个有限的时间为一个哈希（例如100毫秒），并希望给予该约束的攻击者尽可能昂贵的功能。这意味着定制硬件不应该比标准计算机获得更大的优势。因此，最好使用软件友好的哈希，但Keccak相对硬件友好。

   SHA-1和SHA-2在硬件方面也不错，所以在实践中，与其他密码哈希优于PBKDF2-HMAC-SHA-x的优势相比，差异很小。如果你关心的是安全而不是标准的一致性，我推荐scrypt。