Re: [openpgp] Ed25519 and digest choices (issue 31)

Daniel Huigens <> Tue, 25 May 2021 11:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 374423A0BC7 for <>; Tue, 25 May 2021 04:00:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BH2jpMWmVQed for <>; Tue, 25 May 2021 03:59:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0B8203A0BC1 for <>; Tue, 25 May 2021 03:59:56 -0700 (PDT)
Date: Tue, 25 May 2021 10:59:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=protonmail; t=1621940392; bh=ReZtJEvC7SifI182yyl0U6DvrCR7PNJS69suRHL6EHE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=GyO/fqEwbjAJVyaxKrIEsKc94lSBXFe/Buu45zMIJ/7wSZjlvnVWwqAheENuSlq6a nc4iGTfLE/QKM4JxbyBQMEJmRUf1hxAYLZx+kdeAZAZafRYVsuRXsomh+Psf7HnrZP Bds5o5Ng3VpWgFi0K2+OqNeTwJmNsRchQAprhHUk=
To: Daniel Kahn Gillmor <>
From: Daniel Huigens <>
Reply-To: Daniel Huigens <>
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [openpgp] Ed25519 and digest choices (issue 31)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 11:00:02 -0000

Hi dkg,

I believe there's some confusion in the original issue. says that:

   Ed25519 is EdDSA instantiated with:


   |   PH(x)   | x (i.e., the identity function)     |

This is the function that the specification should (and I believe
tries to) reference. The OpenPGP specification indeed pre-hashes the
message as well, but this is irrelevant to (and comes before) RFC8032,
PH(x) is still x. There should be no need to reference PureEdDSA.


‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Friday, May 21st, 2021 at 19:48, Daniel Kahn Gillmor <> wrote:

> Over on, jethrogb
> writes:
> > Appendix A contains an example for EdDSA. The example states that the
> > hash function used is SHA2-256. The example also states that the curve
> > used is 2b06010401da470f01, which is defined as “Ed25519” elsewhere in
> > the draft. However, RFC 8032 specifies Ed25519 as an instantiation of
> > EdDSA with specific parameters, one of which is that H is SHA2-512 and
> > PH (in the ph case) is SHA2-512. Is it the intention that OpenPGP
> > implements not Ed25519 but some other form of EdDSA? If yes, this
> > should be called out explicitly in the text and it shouldn't be called
> > Ed25519. If no, the example needs to be updated and it would probably
> > be good to explicitly call out Ed25519ph in section 14.8.
> How does the WG think this should be resolved?
> I intend to sign this message with an EdDSA signature from a Curve25519
> key, but it will likely use SHA2-256 as the OpenPGP digest choice (in
> the EdDSA RFC 8032 framing, that would be the pre-hash "PH" parameter to
> EdDSA).  This would mean that we are *not* using Ed25519ph, since
> OpenPGP permits variance of the PH parameter.
> One approach would be to clarify that OpenPGP signatures made with
> Ed25519 SHOULD use SHA2-512 as the OpenPGP digest, which I believe would
> align it with Ed25519ph.  But there would still be existing signatures
> out there (like the one signing this message) which would use SHA2-256,
> and it's hard to say that signature verifiers should reject those
> signatures.
> Alternately, maybe we should instead reframe OpenPGP's use of Ed25519 as
> a "PureEdDSA" scheme that signs only the OpenPGP digest (not the signed
> data directly).  That bypasses the "PH" parameter, but it also means
> that any cryptanalsis that is applied to EdDSA isn't necessarily
> applicable to OpenPGP, because we have this additional step involved.
> Either way, it seems that we need to clarify the standard.
>        --dkg
> _______________________________________________
> openpgp mailing list