QCryptographicHash - 实际上SHA3在这里是什么？

Question

我有这样一段代码:

void SHAPresenter::hashData(QString data)
{
    QCryptographicHash* newHash = new QCryptographicHash(QCryptographicHash::Sha3_224);
    newHash->addData(data.toUtf8());
    QByteArray hashResultByteArray = newHash->result();
    setHashedData(QString(hashResultByteArray.toHex()));
    delete newHash;
}

根据Qt规范,QCryptographicHash :: Sha3_224应该"生成一个SHA3-224哈希值.在Qt 5.1中引入".我想比较该代码的结果与其他来源的结果,以检查我是否以正确的方式放置数据.我找到了网站:https: //emn178.github.io/online-tools/sha3_224.html所以我们在两种情况下都有SHA3_224.问题是第一个会从"test"生成这样一个字节串:

3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e

第二个:

3797bf0afbbfca4a7bbba7602a2b552746876517a7f9b7ce2db0ae7b

根本不相似.但也有一个网站做"Keccak-224":https://emn178.github.io/online-tools/keccak_224.html

结果是:

3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e

我知道SHA3是基于Keccak的功能 - 但这里的问题是什么？这两个实现中的哪一个以适当的方式遵循NIST FIPS 202,我们如何知道？

Answer 1

我目前正在为 Java 编写一个 Keccak 库，因此我手边有工具可以测试最初的怀疑。

首先简单总结一下。Keccak是一个海绵函数，可以采用多个参数（比特率、容量、域后缀和输出长度）。SHA-3 只是 Keccak 的一个子集，其中这些值已由 NIST 选择并标准化（在FIPS PUB 202中）。

以SHA3-224为例，参数如下：

bitrate: 1152
capacity: 448
domain suffix: "01"
output length: 224 (hence the name SHA3-224)

需要注意的重要一点是，域后缀是一个位串，它附加在输入消息之后和填充之前。域后缀是区分 Keccak 函数的不同应用（例如 SHA3、SHAKE、RawSHAKE 等）的可选方式。所有 SHA3 函数都使用“01”作为域后缀。

根据文档，我的印象是 Keccak 最初没有域后缀概念，并且 Keccak 团队提供的已知答案测试要求不使用域后缀。

所以，针对你的问题。如果我们采用字符串“test”并使用 ASCII 或 UTF-8 编码将其转换为字节数组（因为 Keccak 工作于二进制，因此文本必须首先转换为字节或位，因此决定使用哪种字符编码很重要使用）然后将其输入真正的 SHA3-224 哈希函数，我们将得到以下结果（以十六进制表示，每行 16 个字节，以便于阅读）：

37 97 BF 0A FB BF CA 4A 7B BB A7 60 2A 2B 55 27
46 87 65 17 A7 F9 B7 CE 2D B0 AE 7B

SHA3​​-224 可以概括为Keccak[1152, 448](M || "01", 224)“M || "01"在输入消息之后、多速率填充之前附加 01”。

然而，如果没有域后缀，我们会得到Keccak[1152, 448](M, 224)孤独M意味着没有附加后缀位，并且多速率填充将在输入消息之后立即开始。如果我们将相同的输入“测试”消息提供给这个不使用域后缀的 Keccak 函数，那么我们会得到以下结果（同样是十六进制）：

3B E3 0A 9F F6 4F 34 A5 86 11 16 C5 19 89 87 AD
78 01 65 F8 36 6E 67 AF F4 76 0B 5E

所以这个结果表明该函数不是SHA3-224。

这一切都意味着您看到的输出差异完全是由域后缀“01”的存在或不存在来解释的（这是我在阅读您的问题时立即怀疑的）。任何声称是 SHA3 的东西都必须使用“01”域后缀，因此要非常警惕行为不同的工具。仔细检查文档，确保它们不要求您在创建/使用对象或函数时指定所需的域后缀，但任何声称是 SHA3 的内容确实不应该让人忘记后缀位。