Hash binding too restrictive?

[falko-strenzke]

The specification of the hash binding currently doesn't allow the stronger hash functions (SHA512 vs. SHA256 and SHA3-512 vs. SHA3-256) for the smaller PQC signature parameter sets. But I think this restriction doesn't make sense. We should better both hash algorithms of the respective family for the smaller parameter set.

[fluppe2]

There might be some reluctance to go with SHA512 or SHA3-512 when using the Category 3 (+ ECC-256) parameter sets. However, let's discuss it in #60.

[wussler]

I think #60 addresses this well

[TJ-91]

Where is it addressed? I think what Falko wants is the following.

Current State in #60:

{: title="Binding between ML-DSA and signature data digest" #tab-mldsa-hash}
Algorithm ID reference | Hash function | Hash function ID reference
----------------------:| ------------- | --------------------------
35, 37, 39             | SHA3-256      | 12
36, 38, 40             | SHA3-512      | 14

Suggested Change (changes in first row):

{: title="Binding between ML-DSA and signature data digest" #tab-mldsa-hash}
Algorithm ID reference | Hash function | Hash function ID reference
----------------------:| ------------------ | --------------------------
35, 37, 39             | SHA3-256, SHA3-512 | 12, 14
36, 38, 40             | SHA3-512           | 14

It doesn't make sense to restrict the implementation to the use of SHA3-256 if instead SHA3-512 is what the implementer/user wants (for whatever reasons). For SLH-DSA in Table 15 it'd be the same: you should be able to sign with SHA-512 or SHA-384 even if it's a SHA-256 parameter set (the same for SHA3).

Do you disagree with that?

I can only imagine interoperability concerns as an argument against it. However, the Preferred Hash Algorithms subpacket exists to signal what hash algorithms to use. And currently, there are no restrictions on the hash algorithms in OpenPGP, so we are more "in line" with the OpenPGP standard if we only restrict the hash-algorithm family and the minimum output length for each signature algorithm instead of a strict one-to-one mapping.

Currently, in the security consideration it is stated:

In order not to extend the attack surface, we bind the hash algorithm used for signature data digestion to the hash algorithm used internally by the signature algorithm.

If we make the change, we should slightly change the security considerations to reflect it, too.

[fluppe2]

We should discuss that interactively during a meeting. I have no objections allowing more signature data digest algorithms, but I don't know if that is what is wanted in terms of simplicity.

BTW: SHA3-256 seems to be an odd choice when you aim for NIST security level 3 Dilithium, as SHA3-256 is level 2. I understand that we chose this due to lacking support for SHA3-384 in the crypto-refresh. For SPHINCS+ we went with SHA(3)-512 for security levels 3 and 5.

[wussler]

Isn't SHA2-256 level 2? Or also SHA3?

[fluppe2]

See https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria)

1. Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 128-bit key (e.g. AES128)

2. Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 256-bit hash function (e.g. SHA256/ SHA3-256)

3. Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 192-bit key (e.g. AES192)

4. Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 384-bit hash function (e.g. SHA384/ SHA3-384)

5. Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for key search on a block cipher with a 256-bit key (e.g. AES 256)

[fluppe2]

With a randomized digest you do not rely on collision resistance. But do people understand this? I guess a straight-forward combination is SHA(3)-384 with Dilithium Level 3. My concern is only that other working groups might look what "they" did in OpenPGP and simply copy the combinations without having the expertise to judge if the combination is fine. However, maybe SHA3-256 is fine if you argue that the randomization ensures that an attacker has to find a preimage and that cost is higher than finding a collision.

[falko-strenzke]

Draft team meeting 2023-09-11: Agrees to leave hash-bindings as specified currently.