Asymmetric Encryption & Digital Signatures

Generate keypairs, sign/verify messages with separate public/private keys, perform key agreement, and compare RSA, ECDSA, and Ed25519 workflows. ECC-specific enrichment stays available when the selected algorithm supports it.

Key Pair Generation

Key Pair Preview
In real systems, private keys must remain secret. This lab shows both keys by default so students can compare the signing key and the verification key side by side.

Digital Signature Workflow

This workflow makes the hashing step explicit, then shows the private/public key split. The signer uses the private key to create a signature; the verifier uses only a public key to check it.
0 bytes
The lab length-prefixes this tag before hashing/signing so the input is unambiguous and students can see how context changes the digest.
1. Hash the Framed Message
Framing rule: len(context) || context || len(message) || message
Current SHA-256 digest
-
Hash input preview (hex)
0 bytes
Edit the message or context and this digest changes immediately, before any signing happens.
2. Sign with the Private Key
The signature field is editable on purpose so students can tamper with it and force a failed verification.
Digest snapshot when the current signature was created
-
Sign a message to capture a signature and digest snapshot.
Format: RSA and Ed25519 produce fixed-length signatures; ECDSA uses DER-encoded (r,s).
3. Verify with a Public Key
The verifier never needs the private key. Swap in the wrong public key to see why verification fails.
Verifier public key preview
Signer public key
Verifier recomputed SHA-256
-
Conceptual flow: Message → Hash → Sign with private key → Verify with public key
Key roles: Private key = sign · Public key = verify
Browser note: WebCrypto signs the framed message bytes using the selected algorithm. The SHA-256 panels are shown explicitly so you can watch the fingerprint change when the message, context, signature, or public key no longer match.
Algorithm note: RSA-2048 mirrors the classic RSA sign/verify story from the lesson. ECDSA P-256 pairs well with the curve intuition panel, and Ed25519 offers deterministic modern signing behavior.

Key Agreement (ECDH)

Generate a shared secret using elliptic-curve Diffie–Hellman (ECDH). Real world: TLS, P2P handshakes, and wallets derive AEAD keys from ECDH via a KDF.

How ECDH Works: The Magic Math

Alice

Private Key (secret)
Public Key (sent to Bob)

Bob

Private Key (secret)
Public Key (sent to Alice)
Shared Secret (KDF output, hex)
This secret feeds into a KDF to derive symmetric keys for AEAD.

Elliptic Curve: One Picture, Full Story

This graph is an intuition aid drawn over the real numbers. Real deployed curves such as P-256 work over finite fields, so the canvas illustrates point-addition ideas without claiming to be the literal production curve.

Curve + Keys

Step 1: Why does it have to be a curve?

The formula y² = x³ + a·x + b creates a special curve because:

  • For each x, you solve for y → get y = ±√(x³ + a·x + b)
  • If the stuff under the square root is positive, you get two possible y values (one positive, one negative)
  • Plotting all these (x, y) points forms a smooth, symmetric curve that loops

Why not just a line or circle? The curve's special shape gives us a mathematical "group" — meaning we can add points on the curve together using geometric rules, and the result is always another point on the same curve. This addition is what powers all the cryptography.

Step 2: What happens if we break the rules?

If you don't follow the math correctly, things break:

  • Bad curve parameters (a, b): If chosen wrong → curve has sharp corners or self-intersects → point addition doesn't work → can't do cryptography
  • G not on the curve: The generator point must be on the curve → if it's not → adding it doesn't follow the rules → public keys are invalid
  • d = 0 or too big: Private key must be in valid range → if d = 0 → Q = 0·G = nothing → can't create signatures
  • Predictable or reused randomness: If you use the same random number twice → attacker solves equations → private key gets stolen

Bottom line: Math has rules. Break them and the security disappears.

Step 3: How are points chosen? (Why randomness matters)

Generator G: Picked once by standards organizations. It's a specific point on the curve that, when you add it to itself repeatedly, cycles through a huge number of different points before repeating. Everyone uses the same G so we're all doing math on the same curve.

Private key d: You pick a completely random number between 1 and (curve order - 1). This randomness is critical:

  • If d is predictable (like always using "12345") → attacker guesses it → your crypto is broken
  • If d is biased (favors certain numbers) → attacker exploits the pattern → your crypto is broken
  • If multiple people reuse the same d → their public keys are identical → easy to track/attack

Public key Q: Computed from d and G using point addition: Q = d·G. Because d is random, Q appears random too — but it's mathematically linked to d through the curve.

What you need to know:
  1. The curve exists because y² = x³ + a·x + b creates a special mathematical structure where points can be added together, and the result is always on the curve.
  2. G (generator) is a fixed starting point that everyone agrees on — it's part of the standard.
  3. d (private key) must be truly random — if it's predictable, reused, or biased, attackers can break your crypto.
  4. Q (public key) = d·G — computed by "multiplying" the generator point by your private key using curve point addition.
  5. Breaking any rule → contradictions → security fails. Math has to be done exactly right, or it doesn't work.
Private Key (d)
Generate keys to see
Public Key (Q = d·G)
Public key appears here
Generator (G)
Fixed base point on the curve
The plotted Q = d·G is a toy visualization derived from your key material for intuition. The hex public key shown in this card is the real exported browser key.

ECDSA Nonce Reuse Concept Demo

ECDSA requires a unique random nonce per signature. If two signatures from the same key reuse the nonce (same r), the private key can be recovered. This section is a conceptual math walkthrough: WebCrypto does not let the browser force a real reused nonce with your live key, so the same-r failure is simulated to show why it is dangerous.

r:   s:
r:   s:
Lesson: If the same r appears in two ECDSA signatures from the same keypair, an attacker can compute the private key. Ed25519 derives its signing randomness deterministically from the secret key and message, which avoids this specific operational mistake.

Address Derivation

In blockchain systems, addresses are derived from public keys via hashing + encoding (e.g., base58check). Real world: Bitcoin (base58check), Ethereum (EIP‑55 checksum). Addresses are shorter identifiers and avoid exposing the raw public key until first spend.

Derivation steps:
1. Hash public key (SHA-256) →
2. Hash again (RIPEMD-160 simulation) →
3. Add version byte + checksum → encode as base58-like
Note: Real address formats vary by blockchain (Bitcoin uses base58check, Ethereum uses hex with checksum, etc.)