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

Question

自 SHA-3似乎是一个已知的函数(Keccak 作为 NIST 哈希函数竞赛的决赛入围者)我有几个与此主题相关的问题:

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

这是我在 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位长度，它应该与提供的 key 长度相同还是像我一样是某个固定的长度？我决定使用固定长度，因为只能使用一些固定值，并且对象 API 用户可以提供任何值作为 key 长度参数，但大多数不常见的值会导致从 SHA3Digest 构造函数内部抛出异常。另外，默认值似乎是 288(当未提供 key 长度时)，这看起来很奇怪。

提前致谢!

Answer 1

1. 关闭是暂时的。 SHA-3 很可能会在 2014 年的某个时候实现标准化。

2. 不，这些值可能适用于 Final Round Keccak，而不适用于 SHA-3。目前还没有 SHA-3 规范，SHA-3 很可能会在标准化之前进行调整。

   =>现在不可能实现SHA-3，只能实现Keccak。

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

   防御者的哈希时间有限(例如 100 毫秒)，并且在给定限制的情况下希望攻击者能够使用尽可能昂贵的函数。这意味着定制硬件不应该比标准计算机获得更大的优势。因此最好使用软件友好的哈希，但 Keccak 相对硬件友好。

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