[openpgp] pure vs. pre-hash in FIPS 204 and 205

[Falko Strenzke <[e-mail]>]

As I had mentioned previously on this list, for the PQC drafts 
draft-ietf-openpgp-pqc and draft-ehlen-openpgp-nist-bp-comp we plan to 
use the pre-hash variants of ML-DSA and SLH-DSA. This is the formally 
correct approach.

However, we realized for two crypto libraries that the author’s 
implementations are using, that the pre-hash variants are not yet 
implemented [1,2]. This might be the case for more crypto libraries, as 
apparently, there is the widespread believe, that hash-and-sign is not 
needed. I attribute this at least in part to a misunderstanding about 
the variants “pure” vs. “pre-hash” in RFC 8032 (EdDSA) as well as FIPS 
204 and 205. The idea is to use the pre-hash variant whenever the 
message is first hashed and then input to the signature algorithm. As I 
had mentioned on this list as well, this is done – formally – wrong in 
RFC 9580, which specifies to use the pure variant of EdDSA to sign the 
hash of the message.

Let us briefly review the background for the existence of the two 
variants. The main point is that the pure and the pre-hash variants are 
domain-separated from each other. This ensures that when both variants 
are added to a protocol, no confusion can arise as whether a message was 
direcly signed or was first hashed and then signed. If the pure variant 
is used in both cases, this confusion can arise and thus a signature 
forgery vulnerability may be introduced into the protocol. This is why 
it is good practice to stick to the right choice of both variants.

However, in OpenPGP, even if the pure variant was used for both 
purposes, as long as this is done specifying different algorithm IDs, no 
signature forgeries are introduced. This is because OpenPGP includes the 
algorithm IDs in the signature digest as part of the meta data, which by 
itself ensures the domain separation.

This leads us to the question whether we should stick to specifying the 
pre-hash variants of the new PQC schemes or whether we should “resign” 
and use the pure variants also here. In order to answer this question, 
comments by implementers are welcome pointing out the situation they are 
facing regarding the support of the pre-hash variants of ML-DSA and 
SLH-DSA in the crypto libraries they depend on.

[1] 
https://github.com/paulmillr/noble-post-quantum/commit/2db3dde2fe411f0eb22175df79b8889e94a0dd90#diff-bc6b97217b17d126c799fe23e332f8a6caf021b3b7e55f6d1bc0f7dddaa613e9
[2] 
https://github.com/randombit/botan/pull/4270#issuecomment-2309574061, 
the link is directly to my comment requesting the addition of the 
pre-hash variant.

- Falko

-- 

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>