Classical Public-Key, Advanced · 6 of 6
Choosing Keys by Strength, Role and Encoding
Why a 256-bit curve key and a 3,072-bit RSA key are equally strong, how they differ in bytes, cost and custody, and why every key should have one job, one home and one lifetime.
Teams usually pick a public-key algorithm once, from habit or a library default, and then live with the consequences for years: certificates that are too large for a constrained device, signing services that cannot keep up, keys that quietly do three jobs at once, and token verifiers that can be tricked by a key in the wrong format. Choosing a key well means answering four separate questions. How strong does it need to be, and which sizes deliver that strength? What exactly is it for? Where will it live and for how long? And how will it be written down and exchanged? This article answers each in turn, starting with why a 256-bit elliptic-curve key and a 3,072-bit RSA key are considered roughly equal, using the comparisons published by the United States National Institute of Standards and Technology (NIST). It then turns to roles, custody, lifetimes and encodings, and ends with the decisions that matter when the key holder is an artificial intelligence (AI) agent rather than a person or a server.
Strength is measured in bits of work
Cryptographers describe the strength of an algorithm and key size as a number of bits of security. A security strength of 128 bits means the best known attack needs roughly 2 to the 128th basic operations, about the same effort as trying every key of a 128-bit symmetric cipher such as the Advanced Encryption Standard (AES). The measure is useful because it puts very different algorithms on one scale.
NIST Special Publication 800-57, its main recommendation on key management, publishes a table of comparable strengths. At 112 bits, the minimum NIST currently accepts, the comparable choices are RSA with a 2,048-bit modulus, finite-field Diffie-Hellman with a 2,048-bit prime, or an elliptic curve of 224 to 255 bits. At 128 bits, they are RSA-3072, finite-field Diffie-Hellman with a 3,072-bit prime, or a 256-bit curve such as P-256. At 192 bits, RSA needs 7,680 bits against a 384-bit curve, and at 256 bits RSA needs 15,360 bits against a curve of 512 bits or more.
The same publication sets timelines. Strength of 112 bits is acceptable for protecting data through 2030; after that, new protection should use at least 128 bits. For anything that must stay confidential or verifiable well beyond that date, 128-bit choices are the sensible starting point today.
Why the sizes differ so much
The gap comes from the attacks, not the arithmetic. RSA and finite-field Diffie-Hellman are attacked with the number field sieve, a method whose running time grows more slowly than any exponential in the key length. Doubling the key does not square the attacker's work, so key sizes must grow quickly to add strength: going from 128 to 256 bits of security needs a five-fold increase in RSA modulus length.
Well-chosen elliptic curves have no known attack of that kind. The best general method, Pollard's rho algorithm, needs roughly the square root of the group size, so a curve with about 2 to the 256th points offers about 128 bits of security, and every added bit of curve size adds half a bit of strength. That is why curve keys stay small and grow slowly.
Two caveats keep this honest. These comparisons concern classical computers only; a large quantum computer running Shor's algorithm would break RSA, finite-field and elliptic-curve keys alike, regardless of size, which is why post-quantum migration is a separate planning item. And the numbers assume sound implementations; a 3,072-bit key used without padding or with a reused nonce is weaker than any table suggests.
| Security strength | RSA or finite-field | Elliptic curve | Status |
|---|---|---|---|
| 80 bits | 1,024 | 160 to 223 | Disallowed |
| 112 bits | 2,048 | 224 to 255 | Acceptable through 2030 |
| 128 bits | 3,072 | 256 to 383 | Recommended for new long-lived use |
| 192 bits | 7,680 | 384 to 511 | Higher assurance |
| 256 bits | 15,360 | 512 and above | Highest assurance |
Bytes, speed and the shape of the cost
Equal strength does not mean equal cost. At 128 bits, an RSA-3072 public key carries a 384-byte modulus and every signature is 384 bytes. A P-256 public key is 65 bytes uncompressed or 33 compressed, and an ECDSA signature is 64 bytes in its raw form, a little more when wrapped in the common Distinguished Encoding Rules (DER) format. An Ed25519 public key is 32 bytes and its signature 64. Across a certificate chain, a handshake or millions of signed tokens, those differences add up.
Speed differs in shape, not just size. RSA verification is very fast because the public exponent is small, but RSA signing and decryption are much slower, and generating an RSA key requires searching for large primes, which can take noticeable time. Elliptic-curve key generation is almost instant and signing is fast, while ECDSA verification is slower than RSA verification. A system that verifies far more often than it signs, such as a software update client, may find RSA verification attractive; a system that signs constantly, such as a token service or an agent platform, usually favours elliptic curves.
Hardware and ecosystem support complete the picture. Older smart cards and hardware modules may support only certain sizes or curves, and some protocols or partners still require RSA. Those constraints are often decisive and should be checked first.
One key, one role
A key pair can technically do several things: an RSA key can sign and decrypt, and an elliptic-curve key can sign and take part in key agreement. NIST's guidance is that a key should be used for a single purpose, a principle called key separation, and there are concrete reasons. Using one RSA key for both decryption and signing can turn a decryption service into a signing oracle, because the two operations use the same private-key arithmetic. Using one key across two protocols lets a message valid in one context be replayed into the other. And separate keys can have separate lifetimes, custody and revocation.
Certificates express the intended role with the key usage extension of the X.509 standard, the format used for web and enterprise certificates: digital signature, key encipherment, key agreement, certificate signing and so on. Verifiers should enforce it, and issuers should set it narrowly.
Seen as data, the relationships are simple. An identity, a person, a service or an agent, holds several keys. Each key has exactly one role and one custody location. A certificate binds one key to one identity for a stated period. Anything that breaks those one-to-one links, such as one key shared by many agents, or one key with several roles, makes compromise larger and investigation harder.
Custody and lifetime
Where a private key lives determines who can misuse it. A key in a file on disk is exposed to anyone who can read that file, including backups and logs. A key in an operating system key store or a Trusted Platform Module (TPM), a security chip built into many computers, is bound to one machine. A key in a hardware security module (HSM) or a cloud key management service never leaves the device; applications ask the device to sign or decrypt and receive only the result, and every use can be logged.
Every key also needs a planned lifetime, which NIST calls a cryptoperiod, after which it is retired. Shorter lifetimes limit how much data a single key protects and how long a stolen key remains useful. SP 800-57 suggests cryptoperiods on the order of one to a few years for private signing keys and much shorter periods for keys that protect traffic, down to a single exchange for ephemeral keys.
SP 800-57 also describes a key's life as a set of states: generated but not yet active, active, deactivated when it should no longer protect new data but may still verify or decrypt old data, compromised if its secrecy is in doubt, and finally destroyed. Planning these transitions in advance, especially the jump to compromised, is what makes rotation and incident response routine instead of an emergency.
Encodings and the algorithm they name
Keys travel in a handful of standard formats. Public keys are usually wrapped in a SubjectPublicKeyInfo structure, which pairs the key bytes with an algorithm identifier, and private keys in the Public-Key Cryptography Standards number 8 (PKCS #8) structure. Both are written in DER binary form or in the text-friendly Privacy-Enhanced Mail (PEM) form, the familiar blocks between BEGIN and END lines. JSON-based systems use the JSON Web Key (JWK) format, which states the key type, such as RSA, EC for P-256 curves or OKP for Ed25519, and for curves the curve name.
The algorithm identifier is not decoration. A long-running class of bugs comes from code that trusts an incoming message to say which algorithm to use with a key, rather than tying the algorithm to the key itself. The best-known example is the JSON Web Token (JWT) algorithm confusion attack: a verifier configured with an RSA public key receives a token claiming to use HS256, a symmetric keyed hash, and naively uses the public key bytes as the shared secret. Since the public key is public, the attacker can forge tokens. The cure is to store each key with its one permitted algorithm and reject anything else.
Encodings also differ in subtle details, such as byte order for Curve25519 keys and compressed versus uncompressed curve points, so conversions between formats should always go through a library rather than manual byte handling.
Planning for change
Key choices age. Strength requirements rise, as the 2030 transition from 112 to 128 bits shows. Algorithms are deprecated, and the eventual arrival of capable quantum computers will require replacing every RSA and elliptic-curve key used for confidentiality and signatures. The ability to change algorithms and keys without redesigning systems is called crypto agility.
Agility starts with an inventory: which keys exist, which algorithm and size each uses, what role it has, where it lives and when it expires. It continues with abstraction, so applications call a signing or key-wrapping service by purpose rather than by algorithm, and with formats and protocols that can carry new algorithm identifiers. Teams that already practise regular rotation find larger migrations much easier, because the machinery for replacing keys already exists.
Decisions for practitioners and AI agents
A good key decision narrows a wide set of options in stages. Start with strength: 128 bits for anything new and long-lived, which means P-256, Curve25519 or Ed25519, or RSA-3072 where RSA is required. Then fix the role, one key per purpose, with matching certificate key usage. Then choose custody, preferring an HSM or key management service for anything valuable, and set a cryptoperiod with automated rotation. Finally, store each key with its single permitted algorithm and exchange it only in standard encodings.
AI agents make these choices urgent. Each agent should have its own identity with its own keys, never one key shared by a fleet, so that a compromise affects one agent and audit logs name the right actor. Signing keys for tokens and requests belong in a key management service, which the agent calls by purpose; they should never appear in prompts, environment variables, container images or logs. Short-lived credentials, refreshed automatically, limit the value of any leak. Token verifiers in agent platforms must pin algorithms per key to rule out confusion attacks. And because agents and code assistants generate configuration and integration code, policy checks should flag oversized lifetimes, shared keys, missing key usage and keys read from files.
None of this is exotic. It is the same discipline good teams apply to services, applied consistently to a fast-growing population of software actors.
- Target 128-bit strength for new long-lived keys.
- One key, one role, one identity; never share keys across agents.
- Keep private keys in an HSM or key management service.
- Set cryptoperiods and automate rotation and revocation.
- Store each key with its single permitted algorithm.
Key takeaways
- Security strength is measured in bits of attack work; NIST's comparable sizes make a 256-bit curve key and RSA-3072 roughly equal at 128 bits.
- RSA and finite-field keys must be much larger because the number field sieve is subexponential, while well-chosen curves face only square-root attacks.
- Equal strength still means different bytes and speed: RSA verifies fast but signs slowly, curves are compact and sign quickly.
- Key separation, one key per role and identity, limits compromise and keeps audit trails meaningful.
- Custody and cryptoperiods matter as much as size: HSMs or key services, planned lifetimes and rehearsed state transitions.
- Bind each key to one algorithm to prevent confusion attacks, and give every AI agent its own short-lived, centrally held keys.
Glossary
- Security strength
- The approximate number of bits of work, as a power of two, needed by the best known attack.
- Number field sieve
- The fastest known classical method for factoring and finite-field discrete logarithms, with subexponential cost.
- Pollard's rho
- A generic method for discrete logarithms that needs roughly the square root of the group size.
- Key separation
- The principle that each key is used for exactly one purpose.
- Cryptoperiod
- The planned span during which a key may be used before it is retired.
- Hardware security module (HSM)
- A tamper-resistant device that stores keys and performs operations with them without exporting them.
- SubjectPublicKeyInfo
- The standard structure that pairs a public key's bytes with an identifier for its algorithm.
- Algorithm confusion
- An attack in which a message tricks a verifier into using a key with the wrong algorithm.
- Crypto agility
- The ability to change algorithms and keys without redesigning the systems that use them.