If you've generated an SSH key in the last decade and seen ecdsa-sha2-nistp256 in the output, you were looking at RFC 5656 in action. This is the spec that taught SSH how to speak elliptic curve cryptography, and it quietly reshaped how billions of secure shell handshakes happen every day.

The problem. The original SSH-2 transport (RFC 4253) standardized only ssh-dss (DSA, 1024-bit) and ssh-rsa. By the mid-2000s both were showing their age. DSA was capped at 1024 bits by the original DSS spec, and RSA keys strong enough to match modern symmetric ciphers were becoming unwieldy: matching a 128-bit AES key requires roughly a 3072-bit RSA key, and matching 256-bit AES requires 15360 bits. Signature verification on those monsters is slow, key files are large, and mobile/embedded devices suffer.

Elliptic curve cryptography solves this arithmetic mismatch. A 256-bit ECC key delivers ~128-bit security; a 521-bit key covers 256-bit. Signatures shrink from kilobytes to dozens of bytes and CPU cost drops by an order of magnitude.

What the RFC actually specifies. Three concrete additions to SSH-2:

• ECDH key exchange — new ecdh-sha2-* methods that replace the finite-field Diffie-Hellman group exchange with elliptic-curve DH. The shared secret K feeding SSH's session-key derivation is now the x-coordinate of an EC point.
• ECDSA host and user keys — ecdsa-sha2-nistp256, -nistp384, and -nistp521, each pinning the curve, the hash (SHA-2 of matching strength), and the wire encoding of the signature as a pair of mpint values.
• MTI curves — the three NIST prime curves above are mandatory-to-implement, so interop across vendors is guaranteed.

Key design decisions worth noting. The authors bound the curve, hash, and key format together into a single algorithm name. This avoids the RSA-era mess where you had to negotiate hash algorithms separately (and ssh-rsa ended up meaning "RSA with SHA-1" long after SHA-1 was broken, requiring the later rsa-sha2-256 patch in RFC 8332). Second, the spec is written as an extensible framework: any curve registered with an ASN.1 OID can be plugged in, which is how curve25519-sha256 (Bernstein's curve, later blessed in RFC 8731) grafted on cleanly.

Why it matters today. Every modern OpenSSH, PuTTY, libssh, dropbear, and Go x/crypto/ssh speaks these algorithms. GitHub, GitLab, and every cloud provider's SSH endpoint negotiates ECDH by default. When you run ssh-keygen -t ecdsa, that's this RFC. When your CI job connects to a bastion in 40 ms instead of 400 ms, thank the elliptic curves.

The quirky backstory. RFC 5656 came out at the tail of a decade-long argument about whether the IETF should endorse the NIST curves at all. Douglas Stebila (then a grad student, now a well-known post-quantum cryptographer) shepherded the draft through multiple revisions while the community debated patent concerns around ECC — Certicom held patents on several point-multiplication optimizations that expired around the time the RFC was published. The NIST curves' choice of "seed" values later became a source of Snowden-era suspicion, which is a big part of why Curve25519 was subsequently added as a preferred alternative. But without RFC 5656 opening the door, none of that follow-on work would have had a place to land.