SHA3状态和PBKDF2-HMAC-SHA3测试载体

Question

1. NIST网站说，由于政府资金不足，NIST已经关闭。SHA-3是否有可能最终被接受？
2. BouncyCastle库有一个SHA-3的实现，其摘要结果与wikipedia文章中发布的示例相同（我对此进行了测试）。既然最终的标准没有得到认可，这还能信任吗？维基百科说这可能会被改变，但怎么改变呢？因为最终的算法似乎不会被改变（否则就是另一种算法）。
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位长度，它应该与提供的密钥长度相同还是与我所做的某个固定的长度相同？我决定使用固定长度，因为只能使用一些固定值，并且object API用户可以提供任何值作为键长参数，但大多数不常见的值会导致从sha3digest构造函数内部引发异常。此外，默认值似乎是288（当没有提供密钥长度时），这看起来很奇怪。

提前道谢！

Answer 1

>

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

不，这些值可能是最后一轮Keccak的值，而不是SHA-3的值。目前还没有SHA-3规范，很有可能在标准化之前对SHA-3进行修改。

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

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