5 minutes estimated reading time.

Generate OpenSSL Elliptic Curve Key Pair from the Command Line

How to generate an OpenSSL elliptic curve (P-256) key pair from the command line, and why NIST-backed ECC beats scaling RSA past 3072-bit.

By Frank Rietta — Published 08/18/2026

Back in 2012, I wrote Generate OpenSSL RSA Key Pair from the Command Line, which has gone on to become the single most-visited post on this entire blog. Fourteen years is a long run for a command-line tutorial, and RSA hasn’t gone anywhere. But if you’re generating a new key pair in 2026, I’d point you toward elliptic curve cryptography (ECC) instead of a bigger RSA key.

The Commands to Run

Generate a P-256 Elliptic Curve Key

Unlike RSA, there’s no dedicated genec command. Elliptic curve keys are generated through OpenSSL’s general-purpose genpkey command instead, where you tell it which algorithm and curve you want:

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -aes256 -out private.pem

That generates a private key on the NIST P-256 curve and writes it, encrypted with AES-256 using a password you provide, to private.pem. That’s the same -aes256 flag and encrypted-output shape I now use in the updated RSA post, since both commands are handled by the same modern OpenSSL machinery under the hood.

Export the Public Key to a File

You still need to extract the public key separately. The command is nearly identical to the RSA version, just using the algorithm-agnostic pkey subcommand instead of rsa:

openssl pkey -in private.pem -pubout -out public.pem

The -pubout flag is still really important. Be sure to include it.

Do Not Run This, it Exports the Private Key

You can make the same mistake here that you can with RSA. Drop -pubout and you export the private key instead of the public key.

openssl pkey -in private.pem -out private_unencrypted.pem

Inspecting the output file, in this case private_unencrypted.pem, shows it starts with -----BEGIN PRIVATE KEY----- with no encryption wrapper at all. That’s your private key, sitting on disk in the clear.

Visually Inspect Your Key Files

You can use less to inspect each of your two files in turn:

less private.pem to verify that it starts with -----BEGIN ENCRYPTED PRIVATE KEY-----
less public.pem to verify that it starts with -----BEGIN PUBLIC KEY-----

The PKCS#8 header doesn’t name the algorithm or curve here either. An EC key and an RSA key that are both AES-256 encrypted look identical from the header alone. If you need to confirm what you actually have, run openssl pkey -in private.pem -text -noout and check the ASN1 OID line for the curve name.

The Generated Key Files

These are throwaway keys, made especially for this post. I do not use them for anything else.

The private.pem file looks something like this:

The public key, public.pem, file looks like:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEBtJ9BLTG8Az37lapvtCcuuk0+Z7N
sMyby8+QdvdsirrJBBGPqo9/jM+dxeRkCaYTXMr7V34j4vQqOuHWwhwjpA==
-----END PUBLIC KEY-----

Notice how much shorter that public key is compared to the 2048-bit RSA one from the earlier post. That’s the whole point.

Why Elliptic Curve Instead of a Bigger RSA Key

Keeping RSA relevant used to just mean scaling the key size up, first 2048-bit, then 3072-bit, then 4096-bit and beyond. NIST SP 800-57 Part 1 Revision 5 publishes a comparable-strengths table for this reason, and it lands on 3072-bit RSA and 256-bit ECC (P-256) as roughly equivalent at 128 bits of security. Past that point, you’re choosing between an RSA key that keeps getting larger and slower, or an EC key that stays small and fast while climbing the same curve-size ladder (P-384, P-521) for more security margin.

The difference isn’t theoretical. I timed 20 back-to-back key generations of each type on the machine used to write this post, an AMD Ryzen 9 9950X (up to 5.6GHz boost clock, though that varies with load rather than holding steady):

rsa4096 keygen: 0.234 sec/key   (~4.3 keys/sec)
ec-p256 keygen: 0.0021 sec/key  (~474 keys/sec)

Generating the key itself is over 100x faster with P-256. That gap holds up, and gets more consequential, once a key is in use. OpenSSL’s own speed benchmark puts RSA-4096 signing at about 1,000 signs/sec on that same chip, against about 98,000 signs/sec for ECDSA P-256, the same ~100x gap on the operation that actually recurs constantly in production, every TLS handshake, every SSH connection. That’s why TLS 1.3, SSH, and most modern PKI defaults have already shifted toward ECC for new deployments. You get equivalent or better security with smaller keys and certificates, and a lot less computational overhead, which matters even more now that so much of this happens on mobile devices and at scale in the cloud.

RSA isn’t broken, and I’m not telling you to rip out working systems. But if you’re standing up something new in 2026 and the only question in your head is how big to make the RSA key, the better question is whether you need RSA at all.

Protecting Your Keys

Protecting these keys follows the same rules as the RSA post, without modification. Back up your private key, keep it secret, and remember that if the key is lost, anything encrypted to it is lost with it too. See Protecting Your Keys in the original post for the fuller version of that advice.

This is part of Rietta’s ongoing coverage of encryption. Browse the Encryption tag for the rest of the series.

Found an issue?

Let us Know

Frank Rietta wrote this article. He is a computer scientist, OWASP Life Member, and expert witness in cases involving computer science and encryption, who founded Rietta in 1999. He has personally written nearly every post here since 2005.