[openpgp] Re: Fwd: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA

["David A. Cooper" <[e-mail]>]

Hello Falko,

The text in Section 5.4 of FIPS 204 and Section 10.2 of FIPS 205 just 
attempts to explain the reason that both "pure" and "pre-hash" versions. 
I'm not familiar with OpenPGP, but it seems like this is a case where 
either version could be used.

 From my reading of Section 5.2.4 of RFC 9580, the content that is 
signed is what is referred to as a trailer. In the case of RSA and 
ECDSA, the trailer is signed directly. The text may describe hashing the 
trailer first and then generating a signature from that hash, but the 
result is the same as just signing the trailer. Section 6.1.1 of 
https://www.ietf.org/archive/id/draft-ehlen-openpgp-nist-bp-comp-00.html 
notes that an ECDSA signature is created by computing a hash of M and 
then performing ECDSA.Sign() on that hash, but "excluding Step 1: H = 
Hash(M) in [the FIPS 186-5 ECDSA] algorithm specification." So, the 
result is the same as signing M with ECDSA using the specified hash 
algorithm. The description for RSA in RFC 9580 is essentially the same.

With EdDSA, however, Section 12.7 of RFC 9580 states to use PureEdDSA to 
sign the hash of the trailer. So, unlike with RSA and ECDSA, from the 
signature algorithm's point of view it is the hash of the trailer that 
is signed. HashEdDSA could have been used to sign the trailer, but that 
was not the decision that was made. (Perhaps the reason is that with 
HashEdDSA, RFC 8032 would have dictated which hash function to use.)

With ML-DSA and SLH-DSA, you could either create a pre-hash signature of 
the trailer (which would align with how RSA and ECDSA work in RFC 9580) 
or a pure signature of the hash of the trailer (which would align with 
how EdDSA works in RFC 9580). Phillip noted that the pre-hash version 
signs the identifier of the hash function, preventing a potential hash 
algorithm substitution attack. However, the trailer seems to already 
include an identifier for the hash function, so a pure signature of the 
hash of the trailer would already be protected from such an attack.

On 8/29/24 1:08 AM, Falko Strenzke wrote:
>
> Hi Dustin,
>
>
> in that case let me formulate the most relevant question that we are 
> facing in OpenPGP currently, that was my main motivation for 
> understanding the quoted paragraphs:
>
>
> OpenPGP is committed to the hash-and-sign paradigm. RFC 9580, the 
> current specification, throughout describes how data is first hashed 
> and then signed. When introducing ML-DSA and SLH-DSA to OpenPGP, we 
> are bound to this approach. The question now is: In such a case, is it 
> a NIST approved solution, to use the pure variants of both PQC schemes 
> to sign the hash value?
>
>
> Best regards,
> Falko
>
>
> Am 28.08.24 um 18:00 schrieb Moody, Dustin (Fed):
>> Falko,
>>
>> We're trying to answer your question, but we don't quite get the 
>> point you're making, which makes it hard to respond. Can you try 
>> explaining it to me again, as clearly as possible so we understand?  
>>  The text seems pretty straightforward to us.
>>
>> Dustin
>>
>>
>> ------------------------------------------------------------------------
>> *From:* [e-mail] on behalf of Falko Strenzke
>> *Sent:* Wednesday, August 28, 2024 12:41 AM
>> *To:* Phillip Hallam-Baker
>> *Cc:* pqc-forum
>> *Subject:* Re: [pqc-forum] Question regarding pure vs. pre-hash ML-DSA
>>
>> Thanks for the pointer. If I see it correctly you are suggesting a 
>> pre-image attack on a hash algorithm that is accepted by the 
>> recipient. Pre-image attacks are not a known threat for any hash 
>> algorithm still potentially in use, not even MD5, as far as I know, 
>> but it's certainly a valid concern to hedge against this possibility. 
>> This would be the reason why the pre-hash variant hashes the hash OID 
>> internally. This is all the more showing how important correct use of 
>> the two variants is and is thus reinforcing my question.
>>
>> My question to NIST actually isn't about technical matters regarding 
>> the security properties of hash algorithms, I am asking how NIST 
>> intends the quoted text is to be understood that is part of their 
>> guidance on using the pre-hash variant.
>>
>> The meaning of the sentence following in the next paragraph is also 
>> not clear to me: "/In order to maintain the same level of security 
>> strength when the content is hashed at the application level or using 
>> HashML-DSA [...]/" This seems to suggest that the content may be 
>> hashed at the application level and then the hash signed with the 
>> pure variant. (That is implied by the "or" connecting the two 
>> clauses.) Possibly here it is referred to a case like that of CMS 
>> where the signedAttrs may be signed and where the message digest is 
>> contained in that object. But I think that doesn't become clear. My 
>> recent experience in a discussion is that this paragraph can be 
>> understood to counter the clear statement at the beginning of section 
>> 5.4:
>>
>> /For some use cases, this may be addressed by signing a digest of the 
>> message along with some domain separation information rather than 
>> signing the message directly. This version of ML-DSA is known as 
>> “pre-hash” ML-DSA or HashML-DSA./
>>
>> Best regards,
>> Falko
>>
>> Am 27.08.24 um 17:29 schrieb Phillip Hallam-Baker:
>>
>>     You can indeed pass the digest directly into pure. The issue
>>     being that it is unsafe to do so, an attacker can perform a
>>     digest substitution attack on it.
>>
>>     Consider the case where the application supports a hash which has
>>     been broken to the extent that they can create any digest output
>>     they like - MD-BORKED
>>
>>     Queen Alice decides to knight Bob, writes out a declaration to
>>     that effect, hashes it with SHA-2-512 and posts it to the gazette.
>>
>>     Mallet takes the signature, writes out a death warrant for Bob
>>     and uses the MD-BORKED manipulation code to create a digest that
>>     matches that of the original message. Instead of arriving to find
>>     the Queen holding a sword to confer the accolade, Bob finds the
>>     headsman holding an axe.
>>
>>
>>     That is why it is always necessary to bind the digest type into
>>     the signature if a pre-hash is used.
>>
>>     Pure should only be used on the message content itself or on a
>>     manifest structure which includes the digest value.
>>
>>     So for example, a DARE signature on a chunk appended to a
>>     sequence typically contains the following information:
>>
>>     * Digest algorithm used to digest the content
>>     * Digest value over the content
>>     * Digest algorithm used to create the Merkle Tree
>>     * Apex value of the Merkle tree
>>     * Witness value showing demonstrating the signer knew the
>>     encryption key
>>     * Application context identifier
>>
>>     Those values are carried in a separate JSON manifest which once I
>>     have finished the code will be signed with ML-DSA pure and with
>>     Ed448 pure with the context string 'DARE manifest'.
>>
>>
>>
>>     On Tue, Aug 27, 2024 at 7:04 AM Falko Strenzke
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Dear NIST team,
>>
>>         in FIPS 204, Section 5.4, I read
>>
>>         /If the content to be signed is large, hashing of the content
>>         is often performed at the application level.
>>         For example, in the Cryptographic Message Syntax [29 ], a
>>         digest of the content may be computed, and
>>         that digest is signed along with other attributes. If the
>>         content is not hashed at the application level, the
>>         pre-hash version of ML-DSA signing may be used./
>>
>>         How is the last sentence to be understood? If the content is
>>         not hashed at the application level, that sounds to me as if
>>         it can be fed into the pure signature generation or
>>         verification routine directly. After all, ML-DSA signature
>>         generation and verification is single-pass over the message,
>>         if I am not mistaken.
>>
>>         On the contrary, my understanding of the pre-hash variant is
>>         that it is specifically for those cases, where the protocol
>>         is bound to compute a hash before it can access (or decide
>>         on) the signature generation or verification function. The
>>         last sentence of the quote, however, seems to suggest that
>>         the pre-hash variant is merely a convenience function to
>>         combine the hash computation with the signature computation.
>>
>>         Can you please clarify?
>>
>>         Best regards,
>>         Falko
>>
>>         --
>>
>>         *MTG AG*
>>         Dr. Falko Strenzke
>>
>>         Phone:
>>         [phone]
>>         E-Mail:
>>         [e-mail] <mailto:[e-mail]>
>>         Web:
>>         mtg.de
>>         <https://www.mtg.de/>
>>         Follow us
>>         ------------------------------------------------------------------------
>>
>>         MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
>>         Commercial register: HRB 8901
>>         Register Court: Amtsgericht Darmstadt
>>         Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
>>         Chairman of the Supervisory Board: Dr. Thomas Milde
>>
>>         This email may contain confidential and/or privileged
>>         information. If you are not the correct recipient or have
>>         received this email in error,
>>         please inform the sender immediately and delete this
>>         email.Unauthorised copying or distribution of this email is
>>         not permitted.
>>
>>         Data protection information: Privacy policy
>>         <https://www.mtg.de/en/privacy-policy>
>>
>>         --
>>         You received this message because you are subscribed to the
>>         Google Groups "pqc-forum" group.
>>         To unsubscribe from this group and stop receiving emails from
>>         it, send an email to [e-mail]
>>         <mailto:[e-mail]>.
>>         To view this discussion on the web visit
>>         https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de
>>         <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/e619b550-178a-4816-8605-8ffb3d0e9c06%40mtg.de?utm_medium=email&utm_source=footer>.
>>
>>