🔐 Cryptography Workbench

Entropy measures unpredictability. A 256-bit key generated from a CSPRNG has 256 bits of entropy. A key derived from the password "password123" has far less — perhaps 20 bits.

Never use Math.random() for cryptography — it is not cryptographically secure. Always use crypto.getRandomValues() or libsodium's randombytes_buf().

Common mistake: Using a timestamp or counter as a "random" value. These are predictable and provide zero cryptographic security.

Keys generated in this demo exist only in browser memory and are lost on page refresh. In production:

• Browser: Use the Web Crypto wrapKey/unwrapKey API or IndexedDB with non-extractable keys
• Server: Use HSMs, key vaults (AWS KMS, HashiCorp Vault), or encrypted key files
• Never: Store keys in plaintext, in source code, or in environment variables without encryption

Keys must be managed through their entire lifecycle (based on NIST SP 800-57):

• Key Generation: Secure, high-entropy creation using a CSPRNG. Ensure keys are unpredictable and robust.
• Key Derivation: KDFs generate encryption keys from passwords or existing keys (e.g., PBKDF2, HKDF).
• Key Registration: Bind key to its owner/application and verify authenticity. Establishes the trust relationship.
• Key Storage: Safeguard against unauthorized access using key wrapping, HSMs, or vault systems. Never store keys in plaintext.
• Key Distribution: Securely transfer keys to intended users/systems while minimizing exposure to interception.
• Key Usage: Use keys only for their intended purpose (encryption, signing, etc.).
• Key Rotation: Periodically change keys to limit the amount of data encrypted with a single key and reduce compromise risk.
• Key Backup & Recovery: Ensure keys can be securely recovered in cases of loss to maintain access to encrypted data.
• Key Revocation: Remove or disable keys that are no longer safe due to compromise or as routine lifecycle management.
• End-of-Life Destruction: Securely delete keys when no longer needed to prevent unauthorized recovery.

Cross-cutting concerns that apply throughout: Access Control (restrict who can use or manage keys based on roles), Audit Logging (track all key usage for compliance and forensics).

Key wrapping encrypts keys with other keys, creating a hierarchy:

• Key Encryption Key (KEK): Used exclusively to encrypt other keys. Stored in an HSM or vault system.
• Data Encryption Key (DEK): Used to encrypt actual data. Wrapped (encrypted) by the KEK for storage.

This separation means compromising the database (where wrapped DEKs are stored) doesn't expose the keys — the attacker also needs the KEK from the HSM.

Key isolation — keeping cryptographic operations separate from application logic:

• HSMs (Hardware Security Modules): Dedicated tamper-resistant hardware that generates keys and performs crypto operations internally. Keys never leave the device.
• TPMs (Trusted Platform Modules): Chip on the motherboard for platform integrity and key storage.
• Secure enclaves: Intel SGX, ARM TrustZone — isolated execution environments within the CPU.
• Vault systems: HashiCorp Vault / OpenBao, AWS KMS, Azure Key Vault, Google Cloud KMS — centralized key management with API-driven encryption/decryption, automatic key rotation, fine-grained access policies, comprehensive audit logging, and Shamir Secret Sharing for unseal operations. The vault performs crypto operations on behalf of applications so keys never leave the vault boundary.

Block Ciphers

Operate on fixed-length chunks (blocks) of data, typically 128 bits (16 bytes).

• AES (Advanced Encryption Standard), originally known as Rijndael, is the most common modern block cipher. Submitted to the NIST competition in 1998, it was standardized as FIPS 197 in 2001. AES is based on a substitution-permutation network (SPN) — each round applies byte substitution (S-box), row shifting, column mixing, and key addition.
• DES (derived from IBM's Lucifer cipher, adopted as FIPS 46 in 1977) and 3DES (standardized as FIPS 46-3 in 1999) are obsolete block cipher algorithms. DES uses a 56-bit key, which is trivially brutable today.

Block ciphers require a mode of operation (ECB, CBC, CTR, GCM) to handle data larger than one block. The mode determines how blocks are chained together — see "Modes of Operation" below.

Stream Ciphers

Operate on data one bit (or byte) at a time by XORing with a pseudorandom keystream.

• ChaCha20 (published 2008) is a modern stream cipher from the ChaCha family, based on Salsa20 (designed 2005). It uses ARX operations — modular Addition, fixed-amount Rotation, and XOR — which are constant-time on all platforms, avoiding timing side-channel attacks.
• ChaCha20-Poly1305 combines the ChaCha20 stream cipher with the Poly1305 MAC for authenticated encryption. Used in TLS 1.3, WireGuard, and Signal.
• RC4 (designed 1987) is an obsolete stream cipher with multiple known vulnerabilities. It was removed from TLS in 2015 (RFC 7465).

Note: AES in CTR or GCM mode effectively turns the block cipher into a stream cipher by encrypting sequential counter values to generate a keystream.

GCM (Galois/Counter Mode) is an authenticated mode: it encrypts data and produces an authentication tag that detects tampering. This is the recommended default.

CTR (Counter Mode) provides confidentiality only — no integrity check. An attacker can flip bits in the ciphertext without detection.

CBC (Cipher Block Chaining) is a legacy mode vulnerable to padding oracle attacks if not combined with a MAC.

ECB (Electronic Codebook) encrypts each block independently with the same key. Identical plaintext blocks produce identical ciphertext blocks, leaking patterns:

CBC fixes this by XORing each plaintext block with the previous ciphertext block before encryption. The IV randomizes the first block:

CBC decryption reverses the process — each decrypted block is XORed with the previous ciphertext block:

Rule of thumb: Always prefer authenticated encryption (GCM or ChaCha20-Poly1305). CBC requires a separate MAC (e.g., HMAC) to provide integrity, and is vulnerable to padding oracle attacks if implemented incorrectly.

An Initialization Vector (IV) or nonce ensures that encrypting the same plaintext with the same key produces different ciphertext each time. Reusing an IV with the same key can catastrophically break security:

• AES-GCM: IV reuse leaks the authentication key, allowing forgery
• AES-CTR: IV reuse produces a two-time pad, revealing plaintext via XOR

AES operates on fixed 128-bit (16-byte) blocks. In GCM mode:

1. Counter mode (CTR) generates a keystream by encrypting sequential counter values (IV + counter). The plaintext is XORed with this keystream — turning the block cipher into a stream cipher.
2. GHASH computes an authentication tag over the ciphertext using polynomial multiplication in GF(2¹²⁸). This tag detects any tampering with the ciphertext or associated data.

The result is ciphertext (same length as plaintext) + a 16-byte authentication tag. The tag is checked during decryption — if it doesn't match, decryption is rejected entirely.

Key sizes: AES-128 uses 10 rounds, AES-192 uses 12 rounds, AES-256 uses 14 rounds. The performance difference is minimal (~15%), so AES-256 is commonly preferred for its larger security margin.

• TLS 1.3: AES-128-GCM and AES-256-GCM are the primary ciphers for HTTPS traffic
• Disk encryption: BitLocker (AES-XTS), FileVault (AES-XTS), LUKS (AES-XTS)
• WireGuard VPN: ChaCha20-Poly1305 (chosen for speed without hardware AES-NI)
• Signal / WhatsApp: AES-256-CBC with HMAC-SHA256 (older) or ChaCha20-Poly1305
• AWS S3 / GCS: Server-side encryption with AES-256-GCM

RSA can only encrypt messages shorter than its key size (e.g., ~190 bytes for RSA-2048 with OWASP + SHA-256). For larger data, real-world systems use hybrid encryption:

Hybrid Encryption:

Hybrid Decryption:

TLS, PGP, and Signal all use this pattern. X25519 + ChaCha20-Poly1305 (libsodium's "box" construction) does this automatically.

OAEP (Optimal Asymmetric Encryption Padding) adds randomized padding before RSA encryption. Without it, RSA is deterministic — the same plaintext always produces the same ciphertext, enabling chosen-plaintext attacks.

PKCS#1 v1.5 padding (the older scheme) is vulnerable to Bleichenbacher's attack. Always use OAEP.

Preimage resistance: Given a hash value h, it should be computationally infeasible to find any input x such that Hash(x) = h. An ideal 256-bit hash has 256-bit security against preimage attacks.

Second preimage resistance: Given an input x₁, it should be infeasible to find a different input x₂ such that Hash(x₁) = Hash(x₂). This ensures you can't substitute a different document with the same hash.

Collision resistance: It should be infeasible to find any two distinct inputs that hash to the same value. Due to the birthday problem, a 256-bit hash offers only ~128-bit collision security — a collision becomes likely (>50%) after ~2¹²⁸ hashes, not 2²⁵⁶.

The birthday bound is why hash output size matters: SHA-256 (256 bits) provides ~128-bit collision security, SHA-512 provides ~256-bit. The pigeonhole principle guarantees collisions must exist (infinite inputs, finite outputs), but finding one should be computationally impractical.

Restricted preimage space: Note that preimage resistance assumes the input space is large. An 8-character password from 70 possible characters has only ~576 billion possibilities (~49 bits of entropy) — easily brutable even at SHA-256's slower speeds. This is why password hashing uses slow algorithms, not fast hashes.

Changing even a single bit of the input should change roughly half the bits of the output. This property makes it impossible to learn anything about the input from the hash.

Hash (e.g., SHA-256): Anyone can compute it. Used for integrity checks, fingerprints, and content addressing.

HMAC (Hash-based Message Authentication Code): Requires a secret key. Proves both integrity and authenticity — only someone with the key can produce or verify the tag.

Use cases: API request signing (HMAC-SHA256), JWT tokens, webhook verification (e.g., GitHub, Stripe).

In 2017, Google's SHAttered project demonstrated the first practical SHA-1 collision — two different PDFs with the same SHA-1 hash. Generating a collision cost ~$110,000 in compute and has dropped since.

SHA-1 should not be used for security purposes. It remains available here for educational comparison only.

SHA-256 uses the Merkle-Damgard construction:

1. Padding: The message is padded to a multiple of 512 bits (64 bytes), with its original length appended.
2. Chunking: The padded message is split into 512-bit blocks.
3. Compression: Each block is processed through a compression function that combines it with the current hash state (8 x 32-bit words) using 64 rounds of bitwise operations, additions, and rotations.
4. Output: The final 256-bit state is the hash digest.

SHA-512 works identically but uses 1024-bit blocks, 80 rounds, and 64-bit words — producing a 512-bit digest. On 64-bit CPUs, SHA-512 can actually be faster than SHA-256 because it uses native 64-bit arithmetic.

• Git: Commit IDs are SHA-1 hashes (migrating to SHA-256)
• Bitcoin: Double SHA-256 for block hashing and proof-of-work
• Package managers: npm, pip, apt verify downloads via SHA-256 checksums
• Content addressing: IPFS, Docker image layers, deduplication systems
• TLS certificates: Signed with SHA-256 (SHA-1 certificates deprecated since 2017)
• HMAC-SHA256: API authentication (AWS Signature V4, Stripe webhooks, GitHub webhooks)

A salt is random data mixed into the hash input. Without it, identical passwords produce identical hashes, enabling rainbow table attacks — precomputed lookup tables of common password hashes.

With a unique salt per user, an attacker must brute-force each password individually, even if two users chose the same password.

PBKDF2 is CPU-hard only — it can be massively parallelized on GPUs (thousands of cores). An attacker with a GPU cluster can test billions of passwords per second.

scrypt and Argon2id are memory-hard: each hash requires a large block of RAM (64MB-1GB). GPUs have limited memory per core, so parallelism is constrained by memory bandwidth, not compute.

Recommendation: Use Argon2id if available, PBKDF2 with 600,000+ iterations as a fallback (OWASP 2023).

Argon2id is a hybrid of two modes:

1. Argon2i (data-independent): Memory access patterns don't depend on the password. Resistant to side-channel attacks (timing/cache) but weaker against GPU brute-force.
2. Argon2d (data-dependent): Memory access depends on the password. Stronger against GPU attacks but vulnerable to side-channel leaks.

Argon2id combines both: the first half of each pass uses Argon2i (side-channel safe), the second half uses Argon2d (GPU-resistant). This gives the best of both worlds.

Parameters explained:

• Time cost (opslimit): Number of passes over memory. More passes = slower = more secure. OWASP suggests 3 for interactive logins.
• Memory cost (memlimit): RAM required per hash. Higher memory makes GPU/ASIC attacks expensive. 256MB is the "moderate" default.
• Parallelism: Number of threads (fixed at 1 in browser). Server-side implementations use 2-4 threads.

Real-world hashcat benchmarks on 2x NVIDIA RTX 3090 GPUs show why algorithm choice matters:

Times assume 8-character random password from 95 printable ASCII characters (95⁸ ≈ 6.6 trillion combinations, average 50% of keyspace). RTX 4090 is roughly 2x faster. An attacker with a GPU cluster can try billions of fast hashes per second — but only thousands of bcrypt/Argon2id hashes per second. This is why password-specific algorithms exist.

A defense-in-depth approach to password storage:

Step 3 (encrypting the hash) adds a layer of defense: even if an attacker steals the password hashes (via SQL injection for example), they still need the encryption key (stored separately, e.g., in an HSM or environment variable) to attempt cracking.

• CWE-261: Weak encoding for passwords (e.g., Base64 is not encryption)
• CWE-760: Using a system-wide salt instead of per-credential salt
• CWE-916: Insufficient computational cost (too few iterations/low cost factor)

Do not:

• Store passwords in plaintext or trivial encoding
• Use fast hashes like sha256(password + salt) — use a proper KDF
• Hard-code passwords in application code
• Use system-wide salts — each credential needs a unique salt

Consider: Using a trusted Identity Provider (SAML2, OpenID Connect SSO) instead of storing credential hashes directly. This delegates password management to a system designed for it.

A signature is bound to the exact message content. Changing even a single character makes the signature invalid.

Try it: Use the main panel to sign a message, then change one character in the message text and click "Verify Signature" — it will fail.

Ed25519 is deterministic: signing the same message with the same key always produces the same signature. This eliminates an entire class of bugs — a bad random number generator during ECDSA signing leaked Sony's PS3 private key in 2010.

RSA-PSS and ECDSA are randomized: each signature differs even for the same message. This is safe when the RNG works correctly, but fragile if it doesn't.

RSA signing is the "reverse" of encryption. Given key pair (e, d, N):

1. Hash the message: h = SHA-256(message)
2. Sign: signature = h^d mod N (using the private key d)
3. Verify: h' = signature^e mod N (using the public key e), then check h' == SHA-256(message)

PSS padding (Probabilistic Signature Scheme) adds a random salt before signing. This means the same message produces different signatures each time, which provides a stronger security proof than the older PKCS#1 v1.5 scheme. Real implementations of RSA require padding schemes like RSA-OAEP to be secure (CWE-780).

ECDSA works differently: it uses a random nonce k to compute a point on the elliptic curve, then derives the signature (r, s) from that point and the private key. If k is ever reused or predictable, the private key can be recovered — this is exactly what happened in the 2010 PS3 key leak. Ed25519 avoids this by deriving the nonce deterministically from the private key and message.

ECDSA and EdDSA provide digital signatures using elliptic curves.

ECDSA Signing

1. Hash the plaintext: h = SHA-256(plaintext)
2. Generate random number k in range [1, n-1]
3. Calculate k * G (generator point), take x-coordinate as r
4. Calculate signature proof: s = k-1 * (h + r * privateKey) (mod n)
5. Signature is (r, s)

ECDSA Verification

1. Hash the plaintext: h = SHA-256(plaintext)
2. Confirm r and s are in range [1, n-1]
3. Calculate modular inverse: s1 = s-1 (mod n)
4. Recover point: R' = (h * s1) * G + (r * s1) * publicKey
5. Take x-coordinate as r'. If r' == r, the signature is valid.

EdDSA Differences

• Uses twisted Edwards curves (Ed25519 uses Curve25519 in Edwards form)
• Generates the nonce deterministically from a hash of the private key and plaintext, eliminating RNG vulnerabilities
• ECDSA is used in TLS; EdDSA (Ed25519) is used in Signal Protocol, SSH, and is preferred for its efficiency and implementation safety

• TLS certificates: Your browser verifies server identity via certificate chains signed by CAs
• Git commits: git commit -S creates GPG/SSH-signed commits
• Software packages: npm, apt, Docker images are all signed
• JWT tokens: RS256/ES256/EdDSA signed claims
• Blockchain: Every transaction is signed by the sender's private key

1. Each party generates a key pair (public + private)
2. Public keys are exchanged openly — an eavesdropper can see them
3. Each party combines their private key with the other's public key
4. Both arrive at the same shared secret

The mathematical structure (discrete logarithm or elliptic curve) ensures that computing the shared secret from two public keys alone is computationally infeasible — this is the Diffie-Hellman problem.

Key exchange security relies on a math problem that's easy in one direction but hard to reverse:

Classic Diffie-Hellman: Given a generator g and a prime p, computing g^x mod p is fast. But given g^x mod p, finding x is computationally infeasible for large p. This is the discrete logarithm problem.

Elliptic Curve (X25519): Instead of modular exponentiation, we use scalar multiplication on an elliptic curve. Given a base point G and a scalar x, computing x·G (adding G to itself x times on the curve) is fast. But given x·G, finding x is hard. Curve25519 was designed by Daniel J. Bernstein to be fast, safe, and resistant to implementation mistakes.

Analogy: Mixing paint colors. It's easy to mix yellow + blue to get green, but given the green, it's nearly impossible to separate it back into the original yellow and blue.

Elliptic curves are defined by an equation of the form y² = x³ + ax + b, where a and b are constants that determine the curve's shape. These curves have useful properties for cryptography:

• Horizontal symmetry: Points reflected over the x-axis remain on the curve
• All non-vertical lines intersect the curve in at most three points

Interactive visualizations (MIT licensed, by Andrea Corbellini):

• Point addition over real numbers — see how a line through two points intersects the curve at a third point
• Point addition over a finite field — see how EC arithmetic works with integer coordinates modulo p
• Scalar multiplication over a finite field — see how k * G produces a seemingly random point (the basis of ECDH/ECDSA)

Point addition on EC over reals
ECClines-3.svg, CC BY-SA 3.0, Emmanuel Boutet

EC over finite field F₆₁
Elliptic_curve_on_Z61.svg, CC0 Public Domain

ECC over a finite field F_p:

• p is a prime defining the field size (a square matrix p x p). Curve arithmetic wraps around at p.
• Only integer coordinates on the curve are used. n (the order) is the total number of integer points on the curve.
• In practice, p and n are 256 bits or longer, providing ~128 bits of security.
• G = generator point (a fixed base point on the curve)
• k = private key (random integer)
• P = public key (point) = k * G using EC point multiplication

Given P and G, it is computationally infeasible to determine k (compute k = P / G). This is the Elliptic Curve Discrete Logarithm Problem (ECDLP).

ECC allows much smaller keys and fewer computations to achieve equivalent security to RSA, making it particularly useful for mobile and low-power devices. ECC can be used directly for key agreement (ECDH) and signatures (ECDSA/EdDSA), but must be combined with a symmetric algorithm for encryption (hybrid scheme).

Run the demo on the left, then check what an eavesdropper on the channel can see:

Basic Diffie-Hellman is vulnerable to Man-in-the-Middle attacks: an attacker who can intercept and modify messages can substitute their own public keys and establish separate shared secrets with each party.

Solution: Authenticate the public keys using digital signatures, certificates (TLS), or out-of-band verification (Signal's safety numbers). This is why key exchange is always combined with authentication in practice.

If you use ephemeral key pairs (generated fresh for each session and discarded afterward), compromising a long-term key does not reveal past session keys. This property is called forward secrecy.

TLS 1.3 requires ephemeral ECDH for every connection. Signal uses the Double Ratchet algorithm, generating new keys for every message.

Trust flows from root CAs (pre-installed in your OS/browser) through intermediate CAs to end-entity certificates (your server's cert).

1. Root CA signs its own certificate (self-signed)
2. Root CA signs intermediate CA certificate
3. Intermediate CA signs server certificate
4. Browser verifies the chain back to a trusted root

Your OS ships with ~150 trusted root certificates. Every HTTPS connection is verified against this trust store.

Certificates serve different purposes, controlled by Key Usage and Extended Key Usage extensions:

Domain Validation (DV) certificates only prove domain control and are the most common type (Let's Encrypt). Organization Validation (OV) and Extended Validation (EV) require additional vetting of the organization's identity, but browsers no longer display EV indicators differently from DV, reducing their perceived value.

Certificate lifetimes have shortened dramatically over the past decade, driven by security concerns:

Why shorter? Shorter lifetimes reduce the window of exposure if a private key is compromised or certificate details become stale. They also force automation — manual certificate renewal doesn't scale at 47-day intervals, making ACME (Let's Encrypt) effectively mandatory.

Let's Encrypt already issues 90-day certificates and is preparing for even shorter lifetimes. Their short-lived certificates initiative explores 6-day certificates that wouldn't need revocation at all — they'd simply expire before most attacks could exploit them.

An X.509 certificate contains:

• Subject: Who the certificate identifies (e.g., CN=www.example.com)
• Issuer: Who signed it (the CA)
• Public key: The subject's public key
• Validity period: Not-before and not-after dates
• Serial number: Unique identifier from the CA
• Signature: CA's digital signature over all the above

The signature is the critical piece: it proves the CA vouches for the binding between the subject and the public key.

If a private key is compromised, the certificate must be revoked. Two mechanisms exist:

• CRL (Certificate Revocation List): CA publishes a signed list of revoked serial numbers. Browsers download and check it periodically.
• OCSP (Online Certificate Status Protocol): Browser queries the CA in real-time for the certificate's status. OCSP Stapling lets the server fetch the response and include it in the TLS handshake, avoiding a separate round-trip.

In practice, browsers like Chrome use CRLSets — a curated, compressed list pushed via browser updates — rather than checking CRL/OCSP for every connection.

Let's Encrypt (launched 2015) revolutionized PKI by offering free, automated certificates via the ACME protocol (RFC 8555). Before it, certificates cost $50-300/year and required manual setup.

Let's Encrypt issues ~4 million certificates per day and serves over 300 million websites. Certificates are valid for 90 days and are auto-renewed, which limits exposure from key compromise.

Certificate Transparency (CT) is a system of public, append-only logs that record all issued certificates. If a CA issues a fraudulent certificate (e.g., for google.com), it will appear in CT logs and be detected.

Since 2018, Chrome requires all new certificates to include CT log entries (SCTs). You can search CT logs at crt.sh.

TLS 1.3 combines four primitives you've explored in the other tabs:

TLS 1.3 removed RSA key exchange entirely — ensuring forward secrecy for all connections. If a server's long-term key is compromised, past sessions remain secure because ephemeral ECDH keys were used and discarded.

In this demo, both parties generate ephemeral ECDH keys — used once and discarded. Even if the server's long-term signing key is stolen tomorrow, an attacker cannot:

• Decrypt previously recorded traffic (the ephemeral keys are gone)
• Forge future connections (they still need to complete a new ECDH exchange)

The signing key only proves identity — it is never used for encryption. This separation of concerns is a core design principle of TLS 1.3.

TLS 1.3 supports only 5 cipher suites (compared to dozens in TLS 1.2):

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

This demo simulates TLS_AES_128_GCM_SHA256 with ECDH P-256 — the most widely used combination.

Real TLS 1.3 includes additional details this demo omits for clarity:

• Certificate chains: Servers present a chain of certificates back to a trusted root CA
• HKDF key schedule: Multiple keys are derived (handshake keys, traffic keys, resumption secrets) via HKDF-Expand-Label
• Transcript hash: A running SHA-256 hash of all handshake messages, ensuring tamper detection
• Finished messages: HMAC over the transcript proves key confirmation
• 0-RTT resumption: Pre-shared keys allow data in the first flight

• Forward secrecy: Compromising current keys cannot decrypt past messages
• Post-compromise security: After a key compromise, security is restored once a new DH ratchet step occurs
• Asynchronous setup: X3DH allows messaging without both parties being online
• Out-of-order delivery: Messages can arrive in any order
• Deniability: Messages cannot be cryptographically attributed to a sender by a third party

• Signal — the reference implementation
• WhatsApp — 2+ billion users since 2016
• Google Messages — RCS encryption
• Facebook Messenger — default E2EE since 2023
• Skype — "Private Conversations" mode

Bitcoin uses the secp256k1 elliptic curve (y² = x³ + 7 over a 256-bit prime field), chosen by Satoshi because it was an underused curve with no suspicious constants — reducing the risk of a backdoor.

The ECDSA tab in this workbench uses P-256 (NIST's standard curve). secp256k1 provides equivalent security but with different performance characteristics. Note: this workbench cannot demonstrate secp256k1 directly because Web Crypto API only supports NIST curves.

The Taproot upgrade (2021) introduced Schnorr signatures (BIP-340) alongside ECDSA:

• Linearity: Multiple signatures can be aggregated into one (MuSig2), making multi-sig transactions indistinguishable from single-sig
• Privacy: Complex spending conditions are hidden until used
• Efficiency: Batch verification is faster than ECDSA

A sufficiently powerful quantum computer running Shor's algorithm could break secp256k1 ECDSA and recover private keys from public keys. However:

• Addresses that haven't spent (public key not exposed) are protected by the hash layer (SHA-256 + RIPEMD-160)
• Grover's algorithm only halves the security of SHA-256 (128 bits remains secure)
• Migration to post-quantum signatures (see PQC tab) is being actively researched

• Lattice-based: ML-KEM, ML-DSA. Fast, compact, well-studied. Most deployed PQC algorithms.
• Hash-based: SLH-DSA, XMSS, LMS. Minimal assumptions (only hash security). Conservative fallback.
• Code-based: Classic McEliece (under evaluation). Very large keys but decades of cryptanalysis.
• Isogeny-based: SIKE was broken in 2022 by a classical attack. This family is largely abandoned.
• Multivariate: Under research. Not yet standardized.

Current deployments use hybrid key exchange: combine a classical algorithm (X25519) with a PQC algorithm (ML-KEM-768). The shared secret is derived from both.

This ensures that if either algorithm is broken (ML-KEM by new cryptanalysis, or X25519 by quantum computers), the connection remains secure. Chrome ships this as X25519Kyber768Draft in TLS 1.3.

The trade-off: TLS ClientHello grows from ~256 bytes to ~1,400 bytes. Measurable but acceptable for most connections.

Estimates vary widely. Breaking RSA-2048 requires ~4,000 error-corrected logical qubits. Current quantum computers have ~1,000-1,500 noisy physical qubits.

Most experts estimate 2030-2040 for cryptographically relevant quantum computers. The "harvest now, decrypt later" threat means we need to deploy PQC for key exchange before quantum computers arrive, even if that's a decade away.

The secret is encoded as the constant term of a random polynomial of degree k-1 over a finite field:

Each share is a point (x_i, f(x_i)) on this polynomial. Given k points, Lagrange interpolation uniquely determines the polynomial and recovers f(0) = secret. With fewer than k points, infinitely many polynomials fit — so no information about the secret leaks.

Example (k=2): Two points define a line. If you know one point, the line could have any slope — the y-intercept (secret) could be anything. With two points, there's exactly one line.

• HashiCorp Vault / OpenBao: Master key is split into shares during initialization. A quorum of key holders must provide shares to unseal the vault.
• Cryptocurrency wallets: Split seed phrases across multiple secure locations so no single breach compromises funds.
• Key escrow: Corporate key recovery where multiple officers must cooperate.
• DNSSEC root key ceremonies: The ICANN root KSK is protected by 14 trusted community representatives, 5 of whom must be present.
• Multi-party computation: Foundation for more complex secret sharing protocols.

HKDF (RFC 5869) operates in two stages:

1. Extract: PRK = HMAC-Hash(salt, IKM) — compresses the input key material into a fixed-length pseudorandom key, even if the input has non-uniform entropy.
2. Expand: OKM = HMAC-Hash(PRK, info || counter) — expands the PRK into as many bytes as needed, using the "info" parameter for domain separation.

The info parameter is critical: it ensures that keys derived for different purposes (encryption vs authentication) are cryptographically independent, even from the same input.

1. Shared secret is established during setup (the QR code you scan)
2. Counter = floor(unix_time / 30) — changes every 30 seconds
3. HMAC: hash = HMAC-SHA1(secret, counter)
4. Truncate: Extract 4 bytes from the hash at a dynamic offset
5. Modulo: code = truncated_value mod 10^digits

HOTP (RFC 4226) is identical but uses a monotonically increasing counter instead of time. TOTP (RFC 6238) builds on HOTP by using time as the counter.

• Phishing vulnerable: TOTP codes can be relayed in real-time by an attacker (unlike FIDO2/WebAuthn)
• Secret compromise: If the shared secret is stolen, all future codes are computable
• Time sync: Server typically accepts codes within a window (e.g., +-1 period) to handle clock drift
• Prefer FIDO2: Hardware security keys (WebAuthn) are phishing-resistant and should be preferred over TOTP where possible

Header: {"alg": "HS256", "typ": "JWT"} — specifies the signing algorithm.

Payload: Contains claims (sub, iat, exp, custom data). Visible to anyone — never put secrets here.

Signature: HMAC-SHA256(base64url(header) + "." + base64url(payload), secret) — proves the token hasn't been modified and was issued by someone with the secret.

• "alg": "none" — Attacker sets algorithm to "none" and removes signature. Server must reject unsigned tokens.
• Algorithm confusion: Server expects RS256 (RSA) but attacker sends HS256 using the public key as HMAC secret. Server must enforce expected algorithm.
• Weak secrets: HS256 with a short/guessable secret allows brute-force. Use 256+ bit random secrets.
• Missing expiry: Tokens without exp claim live forever if stolen.

1. Hash each data block individually: H(block)
2. Pair adjacent hashes and hash each pair: H(H1 + H2)
3. Repeat until one hash remains — the Merkle root

Merkle proofs: To prove a block is in the tree, you only need log₂(n) hashes (the sibling at each level). For 1 million blocks, that's just 20 hashes — not all million.

• Bitcoin: Each block header contains the Merkle root of all transactions. SPV (light) clients verify transactions without downloading the full block.
• Git: Every commit is a hash tree of files. Changing one file changes all hashes up to the commit ID.
• Certificate Transparency: CT logs are append-only Merkle trees of certificates.
• IPFS: Content-addressed storage using Merkle DAGs.
• AWS S3: Uses Merkle trees for data integrity verification.

• Completeness: If the statement is true and both parties are honest, the verifier will be convinced.
• Soundness: If the statement is false, no cheating prover can convince the verifier (except with negligible probability).
• Zero-knowledge: The verifier learns nothing beyond the fact that the statement is true. The interaction could be simulated without the prover.

• Interactive: Prover and verifier exchange messages (like this demo). Requires real-time interaction.
• Non-interactive (NIZK): Prover publishes a single proof anyone can verify. Uses the Fiat-Shamir heuristic to replace interaction with a hash.
• zk-SNARKs: Succinct non-interactive proofs. Small, fast to verify. Used in Zcash and Ethereum rollups.
• zk-STARKs: Transparent (no trusted setup), post-quantum secure, but larger proofs. Used in StarkNet.

• Zcash: zk-SNARKs hide sender, receiver, and amount in transactions
• Ethereum L2 rollups: zk-rollups (zkSync, StarkNet) prove thousands of transactions are valid without re-executing them
• Identity: Prove you're over 18 without revealing your birthdate
• Authentication: Prove you know a password without transmitting it (SRP protocol)
• Voting: Prove your vote is valid without revealing who you voted for