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

Question

由于SHA-3似乎是一个已知的功能(Keccak作为NIST哈希函数竞赛的决赛选手),我有几个与此主题相关的问题:

1. NIST网站称NIST因政府资金失效而关闭.是否有机会最终接受SHA-3？
2. BouncyCastle库有SHA-3的实现,其摘要结果与维基百科文章中发布的示例相同(我对此进行了测试).由于最终标准未获批准,这可以信任吗？维基百科说这可能会改变,但它如何改变,因为最终的算法似乎不是一个改变的主题(否则它将是另一种算法).
3. 这里有人指出应该避免使用带有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.

   =>现在不可能实现SHA-3,你只能实现Keccak.

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

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

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