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")
[GOLDILOCKS].
The use of X25519 and X448 for Elliptic Curve DiffieHellman key exchange
(ECDH) is described in [RFC7748].
Ed25519 and Ed448 are elliptic curve signature schemes Edwardscurve
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 secp256r1
.
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
algorithm/curve combination.
The convention is that "X25519" is used when curve25519 is
used with the DiffieHellman 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 128bit security level equivalent to NIST P256 or
AES128, and the curve448 combinations at around the 224bit security level.
Features of X25519 and Ed25519

The private and public keys for both X25519 and Ed25519 are all represented by a 32byte string.

X25519 allows all 32byte strings as public keys.

Ed25519 allows all 32byte 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 56byte string,
and the private and public keys for Ed448 are represented by a 57byte 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 32byte string as an
X25519 private key and any 56byte 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
length.

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 littleendian convention,
whereas NIST/SEC curves are encoded using the bigendian
convention as per [RFC5915] using the I2OSP primitive defined
in [RFC3447].
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
SIG_SignData
function.
[Contents] [Index]