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散列和。在QT5.1中引入的。”我希望将该代码的结果与其他来源进行比较，以检查我是否以正确的方式放置数据。我找到了网站：224.html，所以我们在这两种情况下都有SHA3_224。问题是，第一个字节字符串将从“test”生成：

3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e

第二项是：

3797bf0afbbfca4a7bbba7602a2b552746876517a7f9b7ce2db0ae7b

一点都不相似。但是也有一个做“Keccak-224”的网站：224.html。

其结果是：

3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e

我知道SHA3是基于Keccak的函数，但这里有什么问题呢？这两个实现中的哪一个以正确的方式遵循NIST FIPS 202，我们如何知道这一点？

Answer 1

目前我正在为Java编写一个Keccak库，所以我手头有一些玩具可以用来测试最初的怀疑。

首先是一个简短的总结。凯克卡克是一个海绵函数，它可以接受许多参数(比特率、容量、域后缀和输出长度)。沙-3只是Keccak的一个子集，NIST (在FIPS酒吧202中)选择并标准化了这些值。

在SHA3-224的情况下，参数如下：

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

重要的是要注意的是，域后缀是一个位字符串，它在输入消息之后和填充之前被追加。域后缀是区分Keccak函数不同应用程序的一种可选方法(如SHA3、way、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函数提供相同的输入"test“消息，那么我们将得到以下结果(同样是十六进制)：

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的内容都不应该忘记后缀位。

Answer 2

这是Qt和在此报道中的一个bug，在Qt5.9中修复了