Add consideration about security level for hashes

[falko-strenzke]

I would move that paragraph to the one where ML-DSA is mentioned explicitely as it does not apply to our choices for SLH-DSA. Also I do not think that we did that on purpose but because of lacking support of SHA3-384 and now we are trying to save our a**es.

Proposal (as I do not know how to submit it as a suggestion over all those lines):

"ML-DSA internally uses a SHAKE256 digest, therefore we require SHA3 in the ML-DSA + ECC signature packet, see {{mldsa-sig-data-digest}}. Note that we bind a NIST security category 2 hash function to a signature algorithm that falls into NIST security category 3. This does not constitute a security bottleneck: because of the random salt that is prepended to the data digest, the hardness assumption is not collision resistance but second-preimage resistance."

I aggree with this, also moving it up by one paragraph is necessary as @fluppe2 suggested.

[fluppe2]

I would also add, that the security argument (i.e. shift from collision to 2nd preimage resistance) is only valid if the random salt is unpredictable for an adversary. Otherwise we are basically back to collision resistance.

So let me alter my proposal slightly:

"ML-DSA internally uses a SHAKE256 digest, therefore we require SHA3 in the ML-DSA + ECC signature packet, see {{mldsa-sig-data-digest}}. Note that we bind a NIST security category 2 hash function to a signature algorithm that falls into NIST security category 3. This does not constitute a security bottleneck: because of an unpredictable random salt that is prepended to the digested data, the hardness assumption is not collision resistance but second-preimage resistance."

Or do you have a better idea how to (at least) mention the necessary assumption on the unpredictability of the random salt?

[falko-strenzke]

"[...] because of an unpredictable random salt that is prepended to the digested data, the hardness assumption is not collision resistance but second-preimage resistance."

Maybe alter this subclause slightly like this: "because of the unpredictable random salt that is prepended to the digested data in v6 signatures, the hardness assumption is not collision resistance but second-preimage resistance."

[fluppe2]

Maybe we should stress the fact that unpredictability is a necessary condition for this argument to apply.

Proposal (with respect to @falko-strenzke):

"because of the random salt that is prepended to the digested data in v6 signatures, the hardness assumption is not collision resistance but second-preimage resistance. However, for this argument to apply the random salt must be unpredictable by an adversary."

[falko-strenzke]

"because of the random salt that is prepended to the digested data in v6 signatures, the hardness assumption is not collision resistance but second-preimage resistance. However, for this argument to apply the random salt must be unpredictable by an adversary."

I am not sure why you want to stress it that much. The word "unpredictable" now occurs two times, do you really think this is necessary? I can also hardly see how someone could come up with an implementation that outputs predictable salts and claim that they are random in the first place. At least in my understanding, unpredictability is implied in randomness. But in any case we are mentioning "unpredictability" already, but I think one time is enough.

[fluppe2]

I'm fine with both approaches (not stressing and stressing it). Stressing it I think (or hope) reminds people that they should use good random numbers here and not say a salt is not so important.

[falko-strenzke]

I'm fine with both approaches (not stressing and stressing it). Stressing it I think (or hope) reminds people that they should use good random numbers here and not say a salt is not so important.

Maybe then it makes sense to add a section under "Security Considerations" that addresses random number generation specifically which also mentions the importance of a "truely" random salt.

[wussler]

Maybe then it makes sense to add a section under "Security Considerations" that addresses random number generation specifically which also mentions the importance of a "truely" random salt.

This is already in the OpenPGP spec:

13.10.  Random Number Generation and Seeding

   OpenPGP requires a cryptographically secure pseudorandom number
   generator (CSPRNG).  In most cases, the operating system provides an
   appropriate facility such as a getrandom() syscall, which should be
   used absent other (for example, performance) concerns...

[wussler]

I've applied the changes @falko-strenzke and @fluppe2, but without the repeated unpredictable. There are many significant attacks that can be carried out in OpenPGP if we drop the assumption of a good CSPRNG and not respecting that security consideration is an expensive mistake already.