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

[Falko Strenzke <[e-mail]>]

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><https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false>
>         Follow us
>         ------------------------------------------------------------------------
>         <https://360-german-security-alliance.de/>
>         <https://www.itsa365.de/de-de/companies/m/mtg-ag>
>
>         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>.
>
> --
>
> *MTG AG*
> Dr. Falko Strenzke
>
> Phone:
> [phone]
> E-Mail:
> [e-mail] <mailto:[e-mail]>
> Web:
> mtg.de 
> <https://www.mtg.de><https://www.linkedin.com/search/results/all/?fetchDeterministicClustersOnly=true&heroEntityKey=urn%3Ali%3Aorganization%3A13983133&keywords=mtg%20ag&origin=RICH_QUERY_SUGGESTION&position=0&searchId=d5bc71c3-97f7-4cae-83e7-e9e16d497dc2&sid=3S5&spellCorrectionEnabled=false>
> Follow us
> ------------------------------------------------------------------------
> <https://360-german-security-alliance.de/> 
> <https://www.itsa365.de/de-de/companies/m/mtg-ag>
>
> 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/f1447b2b-b72e-40be-b4ed-df6b28ae6867%40mtg.de 
> <https://groups.google.com/a/list.nist.gov/d/msgid/pqc-forum/f1447b2b-b72e-40be-b4ed-df6b28ae6867%40mtg.de?utm_medium=email&utm_source=footer>.
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

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>