4

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

  1. NIST 网站称 NIST 因政府资金中断而关闭。SHA-3 是否有可能最终被接受？
  2. BouncyCastle库有一个 SHA-3 的实现，其摘要结果与维基百科文章中发布的示例相同（我对此进行了测试）。既然最终的标准没有通过，这能信吗？维基百科说这可能会改变，但它怎么能改变，因为最终的算法似乎不会改变（否则它将是另一种算法）。
  3. 这里有人指出，应避免将 PBKDF2 与 SHA-3 一起用于密钥强化和密码散列。但我不明白为什么？（如果算法不快，它怎么能给攻击者带来优势？）
  4. 我在任何地方都找不到测试向量来测试我在基于 BouncyCastle java api 的 scala中的PBKDF2 -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 位长度，它应该与提供的密钥长度相同还是像我一样固定？我决定使用固定长度，因为只能使用一些固定值，并且对象 API 用户可以提供任何值作为键长度参数，但大多数不常见的值会导致SHA3Digest构造函数内部抛出异常。此外，默认值似乎是 288（当没有提供密钥长度时），这看起来很奇怪。

提前致谢！

4

1 回答 1

6
  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。

于 2013-10-05T11:42:10.757 回答