What asymmetric crypto is actually for
Symmetric encryption is fast but requires a shared secret first. Asymmetric crypto solves that chicken-and-egg problem: the public key is shareable, the private key stays with you. It is not meant for bulk data, RSA encrypts only data shorter than its modulus and is orders of magnitude slower than AES.
Key-size equivalents
| Security level | RSA | ECC |
|---|---|---|
| ~112 bits | 2048-bit | 224-bit |
| ~128 bits | 3072-bit | 256-bit (P-256) |
| ~192 bits | 7680-bit | 384-bit |
At equal strength, ECC keys and signatures are far smaller, making handshakes faster and messages lighter, which is why modern TLS prefers ECDHE. RSA's advantage is compatibility and mature tooling, including older systems.
Encryption versus signing
- Encrypt (only the recipient can read): encrypt with their public key; they decrypt with their private key;
- Sign (proves origin and integrity): sign with your private key; anyone verifies with your public key;
- Hybrid encryption (what actually happens): exchange or wrap a temporary symmetric key asymmetrically, then encrypt the data with AES. HTTPS works exactly this way.
Four common misuses
- RSA-encrypting large files: use hybrid encryption instead (wrap an AES key with RSA-OAEP);
- Raw PKCS#1 v1.5 encryption: padding-oracle risk, use OAEP;
- Treating the public key as secret: it is public by design; the private key is what you protect;
- Skipping integrity: encrypting without signing or authenticating means tampering goes unnoticed.
Common questions
Will ECC replace RSA? For new systems, largely yes, though legacy and compliance constraints may still mandate RSA. How often should keys rotate? It depends on exposure: long-term signing keys can last 1–2 years, while session keys should change every session.
What it actually does in the field
| Scenario | Primitive used | Why |
|---|---|---|
| HTTPS handshake | Signing + key exchange | Certificates prove identity; ECDHE agrees the session key |
| Code / package signing | Signing | Anyone verifies origin and integrity with the public key |
| SSH login | Signing | The private key stays local; the server stores only the public key |
| Encrypted email | Hybrid | A symmetric key encrypts the body; asymmetric crypto protects only that key |
| Large file transfer | Hybrid | Never RSA-encrypt the payload itself |
Key custody and rotation
- Private keys never enter source control: keep them in a key management service or a tightly permissioned key file;
- Separate keys by purpose: different key pairs for signing and for encryption, so one leak does not compromise both;
- Set a rotation cadence: long-term signing keys every 1–2 years, session keys per session; on suspicion of compromise, revoke and reissue immediately;
- Make revocation visible: published public keys need revocation lists or OCSP, otherwise verifiers cannot tell that a key is dead.
Key size equivalence
- Equivalent strength: RSA 2048 ≈ ECC 224–256, RSA 3072 ≈ ECC 256, RSA 15360 ≈ ECC 521;
- Key and signature size: an ECC 256-bit key is 32 bytes versus 256 bytes for RSA 2048, shrinking certificates and handshake data by an order of magnitude;
- Speed: ECC signs faster with comparable verification; RSA verifies fast but signs slowly, pick based on which side is the bottleneck;
- Compatibility: very old clients may only speak RSA, so deploy both ECC and RSA certificates if you must support them.