小编Ole*_*ura的帖子

由于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(当没有提供密钥长度时),看起来很奇怪.

提前致谢!