X25519 or secp256r1 for key exchange: is the curve choice security or politics?

X25519 or secp256r1 for key exchange: is the curve choice security or politics?

Which named group should you offer first in a TLS 1.3 key share? Both X25519 and secp256r1 (NIST P-256) deliver ~128-bit security, so the distinction is not raw strength — it is provenance and implementation safety.

X25519 (RFC 7748) was designed by Daniel Bernstein with rigidity in mind: its parameters are derived to leave minimal room for hidden weaknesses, and the Montgomery-ladder scalar multiplication is naturally constant-time, resisting timing side channels. secp256r1's constants are NIST-supplied, which fuels a long-running distrust of unexplained seed values, and safe implementation demands more care to avoid invalid-curve and timing pitfalls.

In practice modern stacks negotiate X25519 first and most clients prefer it. P-256 remains essential for compatibility and for environments where FIPS validation mandates NIST curves.

— Offer X25519 first for its implementation safety and clean provenance.
— Keep secp256r1 in the list for compatibility and FIPS-bound deployments.
— Avoid secp521r1 as a default; the cost outweighs any margin you gain.

Further reading: RFC 7748; RFC 8446 §4.2.7; SafeCurves criteria.

Bottom line: prefer X25519 for safer implementation and cleaner pedigree; retain P-256 strictly for compatibility and FIPS obligations.