[openpgp] Re: pre-hashed vs. direct signature PQC schemes

[Daniel Huigens <[e-mail]>]

Hi Falko,

I'm not fully familiar with the pre-hashed variants of ML-DSA and SLH-DSA but if I understand them correctly, the analogy with PureEdDSA and HashEdDSA is not fully correct.

HashEdDSA performs one more hashing step internally than PureEdDSA (see https://www.rfc-editor.org/rfc/rfc8032.html#section-4) the purpose of which is to be able to provide a single-pass (e.g. streaming) interface for signing (which PureEdDSA can't do), but the intended use is still to pass the message to the function, not the hash.

By contrast, [this presentation](https://csrc.nist.gov/csrc/media/Presentations/2024/panel-rehashing-pre-hashing/images-media/panel-pre-hashing-pqc2024.pdf) says that the "normal" variant of ML-DSA and SLH-DSA will take a message and hash it internally, while the pre-hashed version will take a hash and not hash internally. In that case, it makes sense to use the pre-hashed version since the data is already hashed. In the case of EdDSA, it wouldn't make sense to use HashEdDSA (as specified) as that would just add another unnecessary hashing step, rather than take one away.

If we wanted to fully comply with the intended use of EdDSA, what we could have done is specify that we don't prehash the data in OpenPGP and then pass it to HashEdDSA (or PureEdDSA, but then we lose the ability to stream), but that's a much larger change than swapping the variant.

Best,
Daniel

On Tuesday, July 23rd, 2024 at 15:58, Falko Strenzke <[e-mail]> wrote:

> During the session yesterday we mentioned that the NIST standards will specify a pre-hashed as well “direct” variant for the ML-DSA and SLH-DSA signature schemes and that the PQC drafts will use the pre-hashed one. The reason is that the integration of a signature scheme into OpenPGP follows the hash-and-sign paradigm, and this is exactly what the pre-hashed variants are specified for. This is noteworthy as the crypto-refresh took the formally wrong decision of using the PureEdDSA instead of the HashEdDSA variant in the analogous case of EdDSA: there, H(M) is provided to the PureEdDSA variant which is clearly against the intended use of the two variants. This doesn’t have any security implications, as, even if the correct use of the PureEdDSA variant should ever be introduced in OpenPGP, signature forgeries cannot occur since OpenPGP always includes the signature algorithm ID (which would necessarily differ in this case) in the hashed meta data.
>
> So our plan is to do it correctly for the PQC algorithms, even if only in order to demonstrate correct use of the two variants. What we do not mean by this (at least I myself), is changing the use of EdDSA in the ML-DSA+EdDSA multi-algorithm signature scheme. The crypto-refresh specifies already to use PureEdDSA and I would tend to leave it at that also for the new multi-algorithm schemes.
>
> I hope this clarifies what we intend to do and why. Anyone let me know if there is still something unclear.
>
> - Falko
>
> --
>
> MTG AG
> Dr. Falko Strenzke
>
> Phone: [phone]
> E-Mail: [e-mail]
> Web: [mtg.de](https://www.mtg.de)
>
> [Follow us on LinkedIn](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
> ---------------------------------------------------------------
>
> [360° GSA - German Security Alliance](https://360-german-security-alliance.de/)	[Info it-sa 2024](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)