EdDSALegacy with Ed448 curve is incompatible with GnuPG

[andrewgdotcom]

GnuPG represents ed448 curve points in EdDSALegacy algorithms without the specified 0x40 prefix octet.[1] This is apparently intentional, even though it is not (yet) documented.[2]

Is it worth "fixing" the go-crypto implementation of legacy ed448 to be GnuPG-compatible? Since nobody else officially uses legacy ed448, it would appear to be a relatively painless bug-for-bug compatibility fix.

[1] pgpkeys-eu#8 (comment)
[2] https://lists.gnupg.org/pipermail/gnupg-devel/2026-January/036158.html

[twiss]

Apologies for the delayed response.

The implementation of Ed448 in EdDSALegacy in go-crypto was done around the time of draft-ietf-openpgp-crypto-refresh-06, at which time it was specified with the prefix octet. If anyone used it at that time we would need to keep the implementation as-is, but admittedly it seems unlikely as it was never straightforward or encouraged to generate such keys.

Conversely, since Ed448 in EdDSALegacy is now unspecified and not implemented by most implementations (neither matching draft-ietf-openpgp-crypto-refresh-06 nor GnuPG's even-more-nonstandard implementation), I would lean towards just ripping out Ed448 in EdDSALegacy entirely, unless there are strong objections?

[andrewgdotcom]

Update: it turns out that ECDH x448 also uses the prefix-less representation of curve points: https://lists.gnupg.org/pipermail/gnupg-users/2026-May/068298.html