I believe there's some confusion in the original issue.
https://datatracker.ietf.org/doc/html/rfc8032#section-5.1 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
Over on https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/31, jethrogb
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
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.
openpgp mailing list
openpgp mailing list