Curve25519 and Curve448 for the Internet Key Exchange Protocol Version 2 (IKEv2) Key Agreement
Extracted elements (12)
Curve25519 and Curve448 were chosen over NIST curves because they allow faster implementations while being much easier to implement in constant time, making them resilient to time-based side-channel attacks. The NIST curves' generation seeds have no explanation, whereas Curve25519/448 generation is fully documented and independently verifiable.
The shared secret from X25519 or X448 is used directly as g^ir in IKEv2 without additional processing, because the X25519/X448 functions as specified in RFC 7748 already produce output suitable for use as a Diffie-Hellman shared secret.
Brainpool curves (RFC 6954), such as brainpoolP256 (group 28), provide comparable security to Curve25519 and NIST P-256 and are also generated in a fully verifiable way, but are significantly slower due to use of a pseudorandom prime.
Implementations of Curve25519 and Curve448 in IKEv2 SHALL follow the steps described in Section 2, using the X25519 and X448 functions defined in RFC 7748, with all related parameters and encoding compliant with RFC 7748.
Receiving and handling of incompatible point formats MUST follow the considerations described in Section 5 of RFC 7748.
Receiving entities MUST mask the most-significant bit in the final byte for X25519 (but not X448), and implementations MUST accept non-canonical values.
Curve25519 and Curve448 are negotiated in IKEv2 using Transform Type 4 (Diffie-Hellman group) in the SA payload of IKE_SA_INIT or CREATE_CHILD_SA exchanges. The value 31 is assigned to Curve25519 and 32 to Curve448.
Each party picks a secret key d uniformly at random, computes pub_mine = X(d, G), exchanges public keys, and computes SHARED_SECRET = X(d, pub_peer). The shared secret is used directly as g^ir in IKEv2 (RFC 7296 Section 2.14), and is 32 octets for Curve25519 or 56 octets for Curve448.
IANA assigned two new values in the IKEv2 'Transform Type 4 - Diffie-Hellman Group Transform IDs' registry: 31 for Curve25519 and 32 for Curve448, both referencing RFC 8031 for the Recipient Tests field.
Curve25519 and Curve448 are designed to facilitate constant-time implementations, which is of crucial importance especially if ephemeral key pairs are reused across many key exchanges for performance reasons. Implementors are encouraged to use constant-time implementations to resist time-based side-channel attacks.
Curve25519 provides ~128-bit security (comparable to NIST P-256/group 19) and Curve448 provides ~224-bit security. Unlike the NIST curves, the generation process for Curve25519 and Curve448 is fully documented and independently verifiable, preventing malicious parameter manipulation.
The Key Exchange payload carries the public key as Key Exchange Data: 32 octets for Curve25519 (Payload Length = 40) and 56 octets for Curve448 (Payload Length = 64). The Diffie-Hellman Group Num field is 31 for Curve25519 or 32 for Curve448.