QCryptographicHash - what is SHA3 here?

Question

I have a code like this:

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; } 

According to the Qt spec , QCryptographicHash :: Sha3_224 should "generate the SHA3-224 hash amount. Introduced in Qt 5.1". I wanted to compare the result of this code with another source to check if I put the data correctly. I found the site: https://emn178.imtqy.com/online-tools/sha3_224.html So we have SHA3_224 in both cases. The problem is that the first will generate such a byte string from "test":

 3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e 

And the second:

 3797bf0afbbfca4a7bbba7602a2b552746876517a7f9b7ce2db0ae7b 

Not like at all. But there is also a site that makes "Keccak-224": https://emn178.imtqy.com/online-tools/keccak_224.html

And here is the result:

 3be30a9ff64f34a5861116c5198987ad780165f8366e67aff4760b5e 

I know SHA3 is based on Keccak features, but what is the problem? Which of these two implementations corresponds to NIST FIPS 202 appropriately and how do we know this?

Answer 1

I am currently writing a Keccak library for Java, so I had toys that could be checked for initial suspicion.

First a brief summary. Keccak is a sponge function that can take several parameters (bit rate, capacity, domain suffix and output length). SHA-3 is simply a subset of Keccak, where these values ​​were selected and standardized by NIST (in FIPS PUB 202 ).

In the case of SHA3-224, the parameters are as follows:

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

It is important to note that the domain suffix is ​​a bit string that is added after the input message and before filling. A domain suffix is ​​an additional way to distinguish between various Keccak applications (such as SHA3, SHAKE, RawSHAKE, etc.). All SHA3 features use "01" as the domain suffix.

Based on the documentation, I get the impression that Keccak did not initially have the concept of a domain suffix, and tests with the well-known responder provided by the Keccak team require that the domain suffix be not used.

So, to your problem. If we take the “test” String and convert it to an array of bytes using ASCII or UTF-8 encoding (since Keccak works in binary format, so the text must first be converted to bytes or bits, and therefore it is important to determine what character encoding for use), then feed it into the true SHA3-224 hash function, we get the following result (represented in hexadecimal, 16 bytes for a string for easy reading):

 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 can be summarized as Keccak[1152, 448](M || "01", 224) , where M || "01" M || "01" means "add 01 after the input message and before multi-speed filling."

However, without a domain suffix, we get Keccak[1152, 448](M, 224) , where a single M means that no suffix bits are added, and multi-rate filling starts immediately after the input message. If we pass the same test message to this Keccak function, which does not use the domain suffix, then we will get the following result (again in hexadecimal format):

 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 

So, this result indicates that the function is not SHA3-224 .

Which all means that the difference in output that you see is completely explained by the presence or absence of the domain suffix "01" (which was my immediate suspicion when reading your question). Everything that claims to be SHA3 should use the domain suffix "01", so be very careful with tools that behave differently. Carefully check the documentation to make sure that they do not require you to specify the domain suffix you need when creating / using an object or function, but everything that claims to be SHA3 should not really forget the suffix bits.

Answer 2

This is a bug in Qt and is reported here and fixed in Qt5.9