Return-Path: X-Original-To: cfrg@ietfa.amsl.com Delivered-To: cfrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC18C14F694 for ; Fri, 30 Aug 2024 19:45:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.654 X-Spam-Level: X-Spam-Status: No, score=-1.654 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id meLkJDt34OJ3 for ; Fri, 30 Aug 2024 19:45:57 -0700 (PDT) Received: from mail-oo1-f48.google.com (mail-oo1-f48.google.com [209.85.161.48]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F69BC14F5F8 for ; Fri, 30 Aug 2024 19:45:57 -0700 (PDT) Received: by mail-oo1-f48.google.com with SMTP id 006d021491bc7-5df9343b5b8so1548510eaf.0 for ; Fri, 30 Aug 2024 19:45:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725072356; x=1725677156; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ROS9/Vx8Ke3pImN0MRtFMbS/jVBaDExoNoFXlvvl5bY=; b=hvGKZ5/P/8jIaUv5Ml8jstx6HQRqrgtKyfgQRCIZswSaYB/Y/e7lTv14pQFikU+LDg B2q0P9Q2aWs3B8f9EPvXIp7AcoSON5E+Lv68onVytXHzJIuNl6c9vbNz6N49A+ENEzN8 sfePYIWuevyohnA7k+Zsfs5TYBKt6KiIMUGEwtjYpq1wGyt3QUiTT3BvMpLvxgJTl9kX JdRUrcRJkCmMsCuWFQdbnfxWD0LsSLIvlhyqI3TvrvuM9uLGKPiQssBFvgLBXhimXcw1 CYOqrTk1iWZ48kG845wAHmY2Y6FhVQQ8ZIF2dCCSQ/rug8xpwNZnDIZNBars8dMDsYvf OTPQ== X-Forwarded-Encrypted: i=1; AJvYcCVm3j9rmykRftTvLcMk0g4vuiUYyEgsZRlFmNKNxN01HKw5SylyIB1MKZc0vSDtiX4lczJA@irtf.org X-Gm-Message-State: AOJu0Yww7R127/0I5ECvGdbbKZnwSoRFXvizSUrXsBs7yR8VI/4XUhGz f1z+t7lLRStwsVSH/PTtyMS1V0oHPNL8ZBLapNXFWgxs8K1y7N4VyNxqzulPLS7BplE4MyKt7HG of9EkIcyYL8hX0vtaTt8p32btaVE= X-Google-Smtp-Source: AGHT+IFGz+n1gPcNcy32EQoqKvR8GINCfddAf2csgeEPoKA01I5xWDFtJJ9ez3TSQ+JacN5S0Q15OlwdnKD3wF3MZiU= X-Received: by 2002:a05:6820:2292:b0:5df:9279:b0a3 with SMTP id 006d021491bc7-5dfacfc068amr4994495eaf.5.1725072356188; Fri, 30 Aug 2024 19:45:56 -0700 (PDT) MIME-Version: 1.0 References: <6G17q5T00hEi3vAiSOJs5qKpkTAlaEfN3apVelFbTLKSQbXkqa-CSIa1w-HWK93gZSE3V25G_zPODhhw455OYqQmgIMk00rbYSztouk2dYg=@proton.ch> In-Reply-To: <6G17q5T00hEi3vAiSOJs5qKpkTAlaEfN3apVelFbTLKSQbXkqa-CSIa1w-HWK93gZSE3V25G_zPODhhw455OYqQmgIMk00rbYSztouk2dYg=@proton.ch> From: Phillip Hallam-Baker Date: Fri, 30 Aug 2024 22:45:45 -0400 Message-ID: To: Daniel Huigens Content-Type: multipart/alternative; boundary="00000000000000ae1f0620f1b57b" Message-ID-Hash: BMMOR5ESJVT6SRB5E35FTGQICEVIJ2FF X-Message-ID-Hash: BMMOR5ESJVT6SRB5E35FTGQICEVIJ2FF X-MailFrom: hallam@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-cfrg.irtf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: IETF SAAG , IRTF CFRG X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5BCFRG=5D_Re=3A_Prehashing_in_EdDSA_vs_ML-DSA?= List-Id: Crypto Forum Research Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000000ae1f0620f1b57b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The reason pure works for OpenPGP is that they don't sign the digest, they sign a manifest (aka trailer) binding the digest to the digest algorithm. So the rule is that IF you prehash your data, you MUST use a manifest. ML-DSApre is one option for a manifest format, XML Signature JOSE and COSE also define ways to specify manifests. If you are not using ML-DSApre for the manifest, you should use ML-DSA Pure. So given content there are three options. A) Signature =3D MLDSA (sk, content) B) Signature =3D MLDSA (sk, Manifest (Digest(content), DigestAlg)) C) Signature =3D MLDSApre (sk, Digest(content), DigestAlg) What you must not do is D) MLDS (sk, Digest(content)). If people think they need to worry about Quantum Cryptanalysis and not worry about downgrade attacks, well... For EdDSA, the choices are A) Signature =3D EdDSA (sk, content) B) Signature =3D EdDSA (sk, Manifest (Digest(content), DigestAlg)) C) Signature =3D EdDSApre (sk, Digest(content)) WHERE Digest MUST be the on= e specified. I don't think C is remotely practical. I think implementations will end up picking their own content digest. So either they use a manifest format or it will end up failing. This is probably an error that has been caught and avoided. But while we are upgrading systems to ML-DSA, we should take the time to make sure EdDSA was done right. On Fri, Aug 30, 2024 at 4:10=E2=80=AFAM Daniel Huigens wrote: > Hi Phillip, > > On Thursday, August 29th, 2024 at 18:55, Phillip Hallam-Baker wrote: > > There is a lot of confusion among implementers of [ML-DSA] and the > difference between the 'pure' and 'prehash' versions. While working on my > implementation, I am now convinced we just got it wrong in Ed25519 and > Ed448 which do things differently. > > > I personally think a lot of the confusion comes from assumptions people > are making about what the pure and prehash versions are meant to be used > for, that contradict what's actually stated in the specs (both FIPS 204 a= nd > RFC 8032). > > The objective of [HashML-DSA] is to prevent a digest substitution attack > by binding the digest algorithm to the message digest. What it is doing i= n > effect is to create a manifest, prefixing a flag saying 'manifest' and > signing that with ML-DSA-Internal. > > The objective of ML-DSA PURE is to allow direct access to ML-DSA-Internal > to sign messages when the content hasn't been prehashed already. > > > That's not quite what FIPS 204 says, in fact it almost says the opposite: > > > If the content is not hashed at the application level, the pre-hash > version of ML-DSA signing may be used. > > which also implies that if the content *has* been hashed at the > application level, the pure version of ML-DSA should (or must?) be used. > > For binding the hash algorithm that was used to the (pure) ML-DSA > signature, the context parameter could be used as you suggested in the > OpenPGP thread, so using HashML-DSA isn't actually necessary for that. An= d > the spec also says: > > > In general, the =E2=80=9Cpure=E2=80=9D ML-DSA version is preferred. > > This is similar to RFC 8032, by the way, which says: > > > The Ed25519ph and Ed448ph variants are prehashed. This is mainly > > useful for interoperation with legacy APIs, since in most of the > > cases, either the amount of data signed is not large or the protocol > > is in the position to do digesting in ways better than just > > prehashing (e.g., tree hashing or splitting the data). The > > prehashing also makes the functions greatly more vulnerable to > > weaknesses in hash functions used. These variants SHOULD NOT be > > used. > > (...) > > In summary, if a high 128-bit security level is enough, use of > > Ed25519 is RECOMMENDED; otherwise, Ed448 is RECOMMENDED. > > In other words, it is recommended that the protocol preprocesses the data > in some way if necessary (although preferably by tree hashing or chunking= , > in the eyes of this text) and then uses PureEdDSA, rather than using > HashEdDSA. > > For Ed448, the context parameter can be used to prevent domain confusion, > same as for ML-DSA. Pure Ed25519 unfortunately doesn't have a context > parameter, so in that case protocols/applications need to be careful not = to > reuse a key for signing both content and hash digests, but that's usually > not a huge ask. > > > So, even though I think it's a bit confusing that both FIPS 204 and RFC > 8032 introduce variants that they then recommend not to be used, I don't > think there's any huge issue here that needs fixing. > > Best, > Daniel > > > --- > > Daniel Huigens > Cryptography Team Lead > Proton AG > > --00000000000000ae1f0620f1b57b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The reason pure works for OpenPGP is that they don't sign the di= gest, they sign a manifest (aka trailer) binding the digest to the digest a= lgorithm.

<= /div>
So the rule is = that IF you prehash your data, you MUST use a manifest. ML-DSApre=C2=A0is o= ne option for a manifest format, XML Signature JOSE and COSE also=C2=A0defi= ne ways to specify manifests. If you are not using ML-DSApre for the manife= st, you should use ML-DSA Pure.

So given content <content> there are three options.

A) Signature =3D MLDSA=C2=A0(sk, co= ntent)
B) Signature =3D MLDSA=C2= =A0(sk, Manifest (Digest(content), DigestAlg))
C) Signature =3D MLDSApre=C2= =A0(sk, Digest(content), DigestAlg)


What you must not do is D) MLDS (sk, Digest(content)). If people think the= y need to worry about Quantum Cryptanalysis and not worry about downgrade a= ttacks, well...

For EdDSA, the choices are=C2=A0

A) Signature =3D EdDSA (sk, content)
=
B) Signature =3D EdDSA (sk, Manifest (Digest(content), DigestAl= g))
C) Signature =3D EdDSApre= =C2=A0(sk, Digest(content)) WHERE Digest MUST be the one specified.

I don'= ;t think C is remotely practical. I think implementations will end up picki= ng their own content digest. So either they use a manifest format or it wil= l end up failing.

This is probably an error that has been caught and avoided.= But while we are upgrading systems to ML-DSA, we should take the time to m= ake sure EdDSA was done right.

=


On Fri, Aug 30, 2024 at 4:10=E2=80=AFAM Daniel H= uigens <daniel.huigens@proto= n.ch> wrote:
Hi Phillip,<= /div>

<= div> On Thursday, August 29th, 2024 at 18:55, Phillip Hallam-Baker wrote= :
There is a lot = of confusion among implementers of [ML-DSA] and the difference between the = 'pure' and 'prehash' versions. While working on my implemen= tation, I am now convinced we just got it wrong in Ed25519 and Ed448 which = do things differently.

I personally think a lot of the= confusion comes from assumptions people are making about what the pure and= prehash versions are meant to be used for, that contradict what's actu= ally stated in the specs (both FIPS 204 and RFC 8032).

The objective of [HashML-DSA] is to prevent a dige= st substitution attack by binding the digest algorithm to the message diges= t. What it is doing in effect is to create a manifest, prefixing a flag say= ing 'manifest' and signing that with ML-DSA-Internal.

The objecti= ve of ML-DSA PURE is to allow direct access to ML-DSA-Internal to sign mess= ages when the content hasn't been prehashed already.

That's not quite what FIPS 204 says, in fact it almost says the oppo= site:

>=C2=A0If the content is not hashed at the application level, th= e pre-hash version of ML-DSA signing may be used.

which also implies that i= f the content has=C2=A0been hashed at the application level, the pur= e version of ML-DSA should (or must?) be used.

For binding the hash algor= ithm that was used to the (pure) ML-DSA signature, the context parameter co= uld be used as you suggested in the OpenPGP thread, so using HashML-DSA isn= 't actually necessary for that. And the spec also says:

>=C2=A0In = general, the =E2=80=9Cpure=E2=80=9D ML-DSA version is preferred.

=
This is similar to RFC 8032, by the way, whi= ch says:

> The Ed25519ph and Ed448ph variants= are prehashed.=C2=A0 This is mainly
> useful for inter= operation with legacy APIs, since in most of the
>= ; cases, either the amount of data signed is not large or the protocol
> is in the position to do digesting in ways better t= han just
> prehashing (e.g., tree hashing or spli= tting the data).=C2=A0 The
> prehashing also make= s the functions greatly more vulnerable to
> weak= nesses in hash functions used.=C2=A0 These variants SHOULD NOT be
> used.
> (...)
> In summary, if a high 128-bit security level is enough, use of<= /span>
> Ed25519 is RECOMMENDED; otherwise, Ed448 is REC= OMMENDED.

In other words, it is recommended tha= t the protocol preprocesses the data in some way if necessary (although pre= ferably by tree hashing or chunking, in the eyes of this text) and then use= s PureEdDSA, rather than using HashEdDSA.

For E= d448, the context parameter can be used to prevent domain confusion, same a= s for ML-DSA. Pure Ed25519 unfortunately doesn't have a context paramet= er, so in that case protocols/applications need to be careful not to reuse = a key for signing both content and hash digests, but that's usually not= a huge ask.


So, even though I think it's a bit confusing that b= oth FIPS 204 and RFC 8032 introduce variants that they then recommend not t= o be used, I don't think there's any huge issue here that needs fix= ing.

Best,
Daniel


---
=
Daniel Huigens
Crypt= ography Team Lead
Proton AG

--00000000000000ae1f0620f1b57b--