Safe curves for elliptic cryptography
[New in v20.0] The elliptic "safe curve" algorithms
X25519 and Ed25519 are now supported in this Toolkit
and [New in v22.0] so are X448 and Ed448.
X25519 and X448 are key agreement algorithms based on the Montgomery curves
"curve25519" [CURVE25519] and "curve448" (also known as "goldilocks")
The use of X25519 and X448 for Elliptic Curve Diffie-Hellman key exchange
(ECDH) is described in [RFC7748].
Ed25519 and Ed448 are elliptic curve signature schemes Edwards-curve
Digital Signature Algorithm (EdDSA) described in [RFC8032].
Ed25519 uses the twisted Edwards curve "edwards25519", which is
birationally equivalent to curve25519 [ED25519].
curve25519, edwards25519 and curve448 are "safe curves" [SAFECURVES].
These have many security advantages over the standard NIST/SEC curves.
In this documentation we refer to these algorithm/curve
combinations as "safe curves" to differentiate
them from the NIST/SEC elliptic curves such as
There are many differences in the use of these two classes of
elliptic curves, noted below.
The terms "X25519" and "Ed25519" are used to describe the
The convention is that "X25519" is used when curve25519 is
used with the Diffie-Hellman operation,
and "Ed25519" when used for the EdDSA signature operation in
PureEdDSA mode [RFC8410]
(similarly for "X448" and "Ed448").
The curve25519 algorithm/curve combinations are designed to operate at
about the 128-bit security level equivalent to NIST P-256 or
AES-128, and the curve448 combinations at around the 224-bit security level.
Features of X25519 and Ed25519
The private and public keys for both X25519 and Ed25519 are all represented by a 32-byte string.
X25519 allows all 32-byte strings as public keys.
Ed25519 allows all 32-byte strings as private keys.
Ed25519 signatures are always 64 bytes long, with the three
most significant bits of the final byte always zero.
The public keys for X25519 and Ed25519 are derived from the
secret key in different ways and cannot be interchanged.
Features of X448 and Ed448
The private and public keys for X448 are represented by a 56-byte string,
and the private and public keys for Ed448 are represented by a 57-byte string.
Ed448 signatures are always 114 bytes long.
The public keys for X448 and Ed448 are derived from the
secret key in different ways and cannot be interchanged (and anyway are different lengths).
Masking/clamping for X25519 and X448 private keys
There are masking (clamping) requirements for X25519 and X448 private keys
- see Section 5 of [RFC7748] - but these seem to be ignored in published test vectors,
as we do here.
This Toolkit will accept any 32-byte string as an
X25519 private key and any 56-byte string as an X448 private key.
Any required masking will be applied before the key is used.
Some differences from the NIST/SEC curves
The NIST/SEC elliptic curves can be used for both ECDH key
exchange and ECDSA signatures, but Ed25519/Ed448 cannot be used for
key exchange and X25519/X448 cannot be used for signatures.
For NIST/SEC curves, the difference between a private key and
public key is obvious from its structure. This is not the case
for safe curves where the private and public keys are the same
When using the
ECC_ReadKeyByCurve function with
safe curves, the user must explicitly specify whether the key
is a private key or public key.
The hexadecimal encoding of safe curve keys is different from
that used for NIST/SEC keys. Safe curve keys are encoded using
the little-endian convention,
whereas NIST/SEC curves are encoded using the big-endian
convention as per [RFC5915] using the I2OSP primitive defined
The encoding for safe curves used in this Toolkit is
consistent with that used in the reference documents
(other implementations may differ).
When using the ECDSA signature algorithm with the NIST/SEC
curves, you can pass the hash digest of the message to the
signature function to create the signature as an alternative
to passing the entire message.
However, Ed25519 and Ed448 cannot create or verify a signature using the
hash of the message. The full message must be passed
to the sign or verify function.
To sign or verify a file with Ed25519/Ed448, you must read in all the data first
and pass that directly to the