Cryptography / Concepts

Asymmetric Cryptography

Asymmetric cryptography uses mathematically linked pairs of keys: a Public Key that can be shared freely with any endpoint, and a Private Key that must be kept secret by its owner. Asymmetric primitives enable public-key distribution without a pre-shared secret channel and establish ephemeral keys for transport security — but distribution alone does not establish whose key it is; that requires an authenticated binding, such as a CA-issued certificate or an out-of-band fingerprint check. The Certificates page covers the broader Public Key Infrastructure (PKI) trust, validation, issuance, renewal, and revocation lifecycle. A digital signature validates under a public key for specific data, while attribution to a signer additionally depends on that binding and evidence that the private key was not shared, delegated, or compromised.

Asymmetric Paradigm: Linked Key Pairs

Unlike symmetric ciphers which rely on a single shared key, asymmetric cryptography generates a key pair (K_pub, K_priv) with complementary, non-interchangeable roles. For encryption/decryption and sign/verify schemes specifically, an operation performed with one key is inverted or verified by the corresponding key in the pair. Key Encapsulation Mechanisms (KEMs, e.g. ML-KEM) and key-agreement protocols (ECDH/X25519) use the pair differently: encapsulation/decapsulation and Diffie-Hellman-style agreement each compute a shared value from both parties’ key material rather than one key simply inverting an operation the other key performed — the “one key locks, the other unlocks” framing describes encryption and signing, not every asymmetric operation.

Public and private keys have complementary, non-interchangeable roles

Three Distinct Operations

1. Public-Key Encryption (RSA-OAEP direct, or HPKE hybrid): With RSA-OAEP, the sender encrypts a short payload directly under the recipient’s public key. HPKE (RFC 9180) instead uses the public key only to encapsulate a KEM-derived shared secret; a KDF expands that secret into keys for an AEAD cipher, which performs the actual (arbitrary-length) encryption. Either way, only the recipient’s private key can recover the secret.
2. Digital Signatures (Ed25519 / RSA-PSS): The sender computes a signature over data using their private key; anyone holding the corresponding public key can verify that signature for the data. Origin attribution additionally requires a trusted key-to-signer binding and uncompromised key custody.
3. Key Agreement (ECDHE / X25519): Peer endpoints combine their own private keys with each other’s public keys to derive a matching shared secret.

Operations Comparison Matrix

Can I Use a Private Key to Encrypt Data?

Not in any standardized or secure sense. No conforming asymmetric encryption scheme — RSA-OAEP, HPKE, ECIES — defines “encrypt with the private key” as an operation at all; standardized encryption APIs simply don’t expose a private-key-encryption call to make.

A Private Key is used for Digital Signing (and for decrypting incoming data locked under its matching public key). The popular shorthand “signing is encrypting with the private key” is an understandable simplification: for raw/textbook RSA specifically, generating a signature (m^d mod n) and decrypting ciphertext (c^d mod n) really are the same modular-exponentiation primitive with the key roles swapped — PKCS#1 / RFC 8017 names these RSASP1 and RSADP, and they’re defined identically. But treating a signature as “ciphertext” is still inaccurate for three reasons:

1. Signatures Leave Plaintext Intact: Digital signing computes a separate signature tag file (payload.sig) over a message digest while leaving the original payload file (payload.txt) completely unencrypted and readable in cleartext.
2. Standardized Padding Differs and Isn’t Interchangeable: RSA-OAEP (encryption) and RSA-PSS / PKCS#1v1.5 (signing) wrap that shared modular-exponentiation primitive in different, non-interchangeable padding schemes. A valid signature is not a valid OAEP ciphertext: RSA-PSS/PKCS#1v1.5 signature verification is a public-key operation, while RSA-OAEP decryption — which does use the private key, applying RSADP followed by OAEP decoding and padding validation (RFC 8017) — is a different operation over a different padding scheme; treating one as a substitute for the other fails.
3. Most Modern Signature Schemes Have No Encryption Primitive at All: Ed25519, ECDSA, and FIPS 204 ML-DSA are not built from an invertible trapdoor function the way RSA is — there is no “decrypt” operation that recovers anything from one of their signatures, so the RSA-specific shorthand doesn’t generalize to them.

Client-Side Executable RSA Asymmetric Encryption & Digital Signature Playground

Comparative Analysis: RSA vs Elliptic Curve Cryptography (ECC)

To achieve a given Symmetric Security Strength (measured in bits of brute-force work), asymmetric algorithm key sizes scale at drastically different rates. The bit-strength values and required key sizes below come from NIST SP 800-57 Part 1 Rev. 5; the parenthetical labels (“Legacy Minimum,” “Current Standard,” “High Security,” “Maximum Strength”) are this page’s own descriptive shorthand for how each tier is commonly treated in practice, not terminology NIST itself uses:

Comparison of required RSA vs. ECC key lengths in bits across NIST security strength levels (112-bit to 256-bit security)

Why RSA Key Sizes Grow Much Faster Than ECC

1. Security Strength Scaling: The chart compares the required key lengths in bits to achieve equivalent NIST symmetric security levels.
2. Sub-Exponential Attacks on RSA: General Number Field Sieve (GNFS) algorithms allow attackers to factor RSA primes faster than pure brute-force. GNFS runs in sub-exponential time — faster than exponential, but slower than any polynomial — so counteracting it requires RSA key sizes to grow sub-exponentially with the target security level (2,048 bits → 3,072 bits → 7,680 bits → 15,360 bits). This growth is not literally “exponential,” but it is still far steeper than ECC’s scaling.
3. Linear Scaling of ECC: For appropriately selected curves such as those in NIST SP 800-186, there is no known general-purpose classical sub-exponential attack against Elliptic Curve Discrete Logarithms (ECDLP) — the best known generic attack (Pollard’s rho) costs roughly 2^n/2 for an n-bit curve group, so security strength scales roughly linearly with curve size, at about half the curve’s bit length. This reflects the current state of cryptanalysis, not a proof that no future or curve-specific algorithm exists. It is the mental model behind the table above (224 → 256 → 384 → 521 bits); the specific NIST-approved curve sizes are discrete parameter choices dictated by NIST SP 800-57 Part 1 Rev. 5’s strength ranges, not an exact doubling sequence.
4. Engineering Consequence: At 192-bit security, RSA requires a 7,680-bit key, compared with a compact 384-bit ECC key. Large RSA private-key operations such as signing or decryption therefore incur substantially more CPU and bandwidth overhead than the corresponding ECC operations; the exact difference depends on the operation, implementation, and hardware.

Why Ed25519 (EdDSA) is Preferred for Modern Applications

Specified in RFC 8032, Ed25519 offers major advantages over legacy ECDSA:

• Deterministic Nonce Derivation: Ed25519 derives its per-signature nonce deterministically from the private key and message hash, eliminating catastrophic ECDSA private key leaks caused by weak random number generators.
• Side-Channel & Timing Attack Resistance (Implementation-Dependent): Ed25519’s Edwards-curve arithmetic admits complete addition formulas that avoid conditional branching on secret data, making constant-time implementations easier to write correctly than for curves lacking this property. This is a property the algorithm enables, not a guarantee every implementation delivers — a careless or unoptimized implementation can still leak key material through cache-timing, power analysis, or other side channels.

Public-Key Input Validation: Why Accepting a Key Isn’t Enough

Asymmetric protocols must validate peer-supplied key material before using it, not just successfully parse its encoding — several well-known attack classes exploit implementations that skip this step:

• Invalid-curve attacks: This applies specifically to short-Weierstrass curves (NIST P-256/P-384/P-521 and similar) used with standard ECDH: an attacker sends a point that doesn’t actually satisfy the expected curve equation, and without a curve-membership check before scalar multiplication, the arithmetic silently proceeds using a different, often much weaker, effective curve that shares some parameters with the real one — letting the attacker leak bits of the victim’s static private key across repeated queries. Validated short-Weierstrass ECDH implementations check curve membership on every received point. X25519’s Montgomery-curve formulation is a different case (see the low-order-input point below) — it isn’t validated the same way, and “check curve membership” isn’t the applicable defense there.
• Small-subgroup attacks: Curve groups with a cofactor greater than 1 contain small-order subgroups alongside the main large-order group. A point of small order forces the resulting shared secret into a tiny, enumerable set of values; against a responder that reuses a static key and doesn’t detect this, an attacker can recover the static private key modulo that small subgroup’s order through repeated probes, and combine several such probes (with different small subgroups) to reconstruct more of the key via the Chinese Remainder Theorem.
• Low-order X25519 inputs: X25519 has a handful of publicly known low-order points; RFC 7748 §6.1 specifically identifies that such inputs decode to a fixed, attacker-predictable all-zero shared-secret output, regardless of the other party’s private key. RFC 7748 permits implementations to skip full point validation for performance, since X25519’s Montgomery-ladder design tolerates invalid inputs without leaking the private key; the RFC itself only says implementations MAY check for and reject an all-zero output, not that they must. In practice, most security guidance and higher-level protocols treat that check as effectively mandatory — silently accepting an all-zero shared secret hands the attacker a session key they already know — so don’t read RFC 7748’s permissive wording as license to skip the check; treat it as a protocol- or deployment-specific requirement layered on top of the RFC’s baseline. Whether rejection is mandatory for a given deployment is protocol-specific rather than something RFC 7748 itself dictates.
• RSA-OAEP message-size limits: RSA-OAEP’s maximum plaintext length is bounded by the modulus and hash sizes — mLen ≤ k - 2×hLen - 2 bytes, where k is the RSA modulus size in bytes and hLen is the hash output size. This is not a soft limit; a well-formed OAEP implementation rejects an oversized message outright rather than silently truncating it. RFC 8017 §7.1 does permit RSA-OAEP to directly encrypt any message within that size bound — the interactive playground above does exactly this for a short demo payload — but treating RSA-OAEP as capable of encrypting arbitrary-length or bulk payloads directly is a common integration mistake: production systems normally use RSA-OAEP to wrap a short symmetric key (see Hybrid Encryption below) rather than encrypt bulk data directly, since the size bound makes direct encryption impractical for anything beyond a small payload.
• Key confirmation: A successfully computed shared secret proves the arithmetic executed, not that the peer is who they claim to be, or even that both sides actually derived the same value — an implementation bug could have each side silently compute a different secret. Protocols add an explicit key-confirmation step (a MAC or Finished-style message computed over the derived key material, exchanged and checked before either side trusts the channel) specifically to catch key-agreement mismatches, rather than assuming a completed exchange implies a working, authenticated channel.

Primary references

• RFC 9180: Hybrid Public Key Encryption (HPKE) — IETF RFC 9180
• NIST SP 800-56B Rev. 2: Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography — NIST CSRC SP 800-56B