Undocumented novel Ed448 point encoding breaks interoperability

Andrew Gallagher andrewg at andrewg.com
Mon Jan 5 14:55:36 CET 2026


Hi,

It has been brought to my attention that Ed448 keys are being encoded 
without prefix octets in their MPIs/SOSes, which breaks compatibility 
with go-crypto (and perhaps others) and is not documented anywhere that 
I can find. The librepgp specification requires prefix octets for all 
ECC curve point representations.

The offending code appears to be in libgcrypt/cipher/ecc.c:

```
rc = _gcry_ecc_eddsa_encodepoint (ec->Q, ec, Gx, Gy,
                                   (ec->dialect != ECC_DIALECT_SAFECURVE
                                    && !!(flags & PUBKEY_FLAG_COMP)),
                                   &encpk, &encpklen);
```

https://github.com/gpg/libgcrypt/blob/9e3af928ee1100fc979a75dd4ae6a4ace2c36bef/cipher/ecc.c#L775

This selectively uses prefix octets (or not) depending on the value of 
`ec->dialect`, which is only set to `ECC_DIALECT_SAFECURVE` for ed448. 
This means that ed448 curve points are noncompliant with section 13.3 of 
the librepgp specification, which reads:

> The EdDSA algorithm defines a specific point compression format. To indicate the use of this compression format and to make sure that the key can be represented in the Multiprecision Integer (MPI) format the octet string specifying the point is prefixed with the octet 0x40. This encoding is an extension of the encoding given in [SEC1] which uses 0x04 to indicate an uncompressed point. For example, the length of a public key for the curve Ed25519 is 263 bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the native value of the public key.

https://datatracker.ietf.org/doc/html/draft-koch-librepgp#name-eddsa-point-format

Ed25519 follows the above spec, but Ed448 does not. Is this an error in 
the specification or an error in the implementation?

A




More information about the Gnupg-devel mailing list