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

[Simo Sorce <[e-mail]>]

Hello David,
your response mentions that both "pure" and "pre-hash" variants would
be ok for openpgp.

The spec expresses a recommendation to use Pure ML-DSA (quoting: `In
general, the “pure” ML-DSA version is preferred.`) and this has been
taken, by some, to mean that applications should prefer the use of ML-
DSA even when the content being signed is pre-hashed.

Can you clarify if NIST would recommend the use of HashML-DSA when the
message is pre-hashed, all else equal?

Or would NIST recommend to use the pure ML-DSA, regardless of what form
the message takes and relegates HashML-DSA just to cases where there is
a technical deficiency in the Crypto module implementation that makes
pure ML-DSA impractical for large messages ?

Thank you,
Simo.

On Thu, 2024-08-29 at 12:05 -0700, 'David A. Cooper' via pqc-forum
wrote:
> 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>.
> > > 
> > > 
> 

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc