Public Key Cryptography Basics: How Secure Sharing Works

Public key cryptography — also called asymmetric cryptography — uses two mathematically linked keys: a public one you can hand out freely and a private one you guard. Encrypt something with my public key, and only my private key can read it. This solves the oldest problem in cryptography: how two strangers who have never met can share a secret over an open channel. Invented by Diffie and Hellman in 1976 and made practical by RSA a year later, it's now the foundation of TLS 1.3, Signal, SSH, Ed25519 code signing, and every file transfer service that authenticates users. Here's how it actually works.

The mathematical trapdoor

All public-key cryptography relies on "trapdoor" functions — computations that are easy to do forward but effectively impossible to reverse without extra information. Two families dominate:

• Integer factorization (RSA): multiplying two large primes is trivial; factoring their product is exponentially hard. A 2048-bit RSA key uses two ~1024-bit primes. The best known attack, General Number Field Sieve, takes roughly 2^112 operations — out of reach.
• Discrete logarithms over elliptic curves (ECDH, ECDSA, Ed25519): computing point multiplication on a curve is fast; reversing it to find the multiplier is hard. 256-bit curves like Curve25519 give equivalent security to 3072-bit RSA.

Both problems are easy for quantum computers via Shor's algorithm, which is why NIST standardized post-quantum alternatives (ML-KEM and ML-DSA) in FIPS 203–205 in 2024.

RSA in practice

Ron Rivest, Adi Shamir, and Leonard Adleman published RSA in 1977. The scheme is elegant:

1. Pick two large primes p and q.
2. Compute n = p × q (the modulus) and φ(n) = (p-1)(q-1).
3. Pick e coprime to φ(n), commonly 65537.
4. Compute d such that e × d ≡ 1 (mod φ(n)).
5. Public key: (n, e). Private key: (n, d).

Encryption: ciphertext = message^e mod n. Decryption: message = ciphertext^d mod n. The math works because of Euler's theorem.

Real-world RSA uses OAEP padding (RFC 8017) to prevent chosen-ciphertext attacks. Textbook RSA is catastrophically insecure. RSA-2048 is the current minimum for new systems; RSA-3072 or 4096 for anything long-lived.

Diffie-Hellman: shared secrets without shipping keys

RSA lets you encrypt to a known recipient. Diffie-Hellman does something subtly different: it lets two parties derive a shared secret over a public channel, without either sending the secret.

The classic version (DH over integers modulo a large prime):

1. Both parties agree on a large prime p and generator g.
2. Alice picks secret a, sends A = g^a mod p.
3. Bob picks secret b, sends B = g^b mod p.
4. Alice computes B^a mod p = g^(ab) mod p.
5. Bob computes A^b mod p = g^(ab) mod p.

Both arrive at g^ab mod p without ever sending a or b. An eavesdropper sees g, p, A, B but computing g^ab from A and B requires solving the discrete logarithm problem.

Modern DH uses elliptic curves (ECDH). X25519 is the standard choice: 32-byte keys, 32-byte shared secrets, implementation-hardened against timing attacks.

Elliptic curves and why they won

RSA feels old because it mostly is. Elliptic curve cryptography replaced it for three practical reasons:

• Smaller keys. A 256-bit EC key gives the security of a 3072-bit RSA key. That's 32 bytes vs 384 bytes.
• Faster operations. ECDH on Curve25519 takes roughly 70 microseconds on a modern CPU. RSA-3072 key generation takes seconds.
• Better randomness resilience. Ed25519 is deterministic — signatures don't require per-message random nonces, avoiding the Sony PS3 ECDSA disaster of 2010 where a constant nonce leaked the master key.

NIST curves (P-256, P-384, P-521) are widely supported but historically distrusted by some cryptographers over unexplained constants. Curve25519 and Ed25519, designed by Daniel Bernstein, are the modern defaults used in TLS 1.3, WireGuard, Signal, and SSH.

Signatures: proving who sent what

Public-key crypto does something symmetric can't: prove authorship. Signing reverses the encryption roles — you "encrypt" (sign) with your private key, and anyone with your public key can "decrypt" (verify). If it verifies, you must have held the private key.

Real signatures use hash functions to handle arbitrary-sized messages:

1. Compute h = SHA-256(message).
2. Sign h with the private key (RSA-PSS, ECDSA, or Ed25519).
3. Verifier hashes the received message, checks against the signature with the public key.

Applications: TLS certificates (the CA signs the site's public key), code signing (Apple's notarization, Microsoft Authenticode), Git commit signing, software package managers (apt, Homebrew, npm).

Where file transfer uses public key crypto

For anonymous link-based transfers (SwissTransfer, HexaTransfer), public-key crypto often doesn't appear directly — a random symmetric key in the URL fragment handles everything. But for account-based services, public keys matter:

• TLS 1.3 server authentication. Every HTTPS connection starts with the server's certificate, verified against a CA chain. Ephemeral ECDHE key exchange then derives the session key.
• Account-to-account encryption. Tresorit, Proton Drive, and Mega each give users a key pair at signup. Files shared between accounts are wrapped with the recipient's public key.
• Signed clients and updates. Desktop apps verify updates with Ed25519 or RSA signatures to prevent supply-chain attacks.
• Password-less auth. WebAuthn and Passkeys use EC keys stored in secure hardware (Touch ID, Windows Hello, YubiKey).

Key distribution: the remaining hard problem

Public-key crypto solves one key-distribution problem but creates another: how do you know a public key really belongs to whom it claims? Three models:

• PKI (Public Key Infrastructure). Certificate authorities sign public keys. Used by TLS with roots in Chrome, Firefox, Safari.
• Web of trust. PGP's approach — users sign each other's keys. Flexible but scaling problems kept adoption niche.
• TOFU (Trust On First Use). SSH's approach — accept the key the first time, warn if it changes. Simple but vulnerable to initial interception.
• Key transparency. Merkle-tree logs where all public keys are publicly auditable. Used by WhatsApp, iMessage Contact Key Verification, and modern passkey systems.

For file transfer with unknown recipients, URL-fragment sharing sidesteps this entirely — the sender hands the recipient the key directly via the link, and authenticity depends on the channel used to share the link.

What quantum computing changes

A large-scale quantum computer running Shor's algorithm breaks both RSA and elliptic-curve cryptography. Current estimates put the timeline at 10–20 years, but the risk is immediate for data with long shelf lives: "harvest now, decrypt later" attacks record encrypted traffic today and decrypt it in 2040.

NIST's 2024 post-quantum standards:

• FIPS 203 (ML-KEM) — replaces Diffie-Hellman / ECDH for key exchange. Based on lattice problems.
• FIPS 204 (ML-DSA) — replaces RSA/ECDSA for signatures.
• FIPS 205 (SLH-DSA) — hash-based signature backup.

Cloudflare and Google now support ML-KEM in TLS 1.3 key exchange. File transfer services will follow over the next few years. Symmetric encryption (AES-256-GCM) is largely unaffected — Grover's algorithm only halves its effective strength.

Putting it together

For sensitive shares today: TLS 1.3 with X25519 key exchange protects the connection, AES-256-GCM handles bulk encryption, and for account-based services, ECDH with Curve25519 wraps per-file keys. Link-based services skip the account layer but gain simplicity. Both models deliver strong security when implemented correctly.

Try it at hexatransfer.com — free, no account, 10 GB max.