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 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 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 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 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 little-endian convention, whereas NIST/SEC curves are encoded using the big-endian 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]