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
This lab shows both key values 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; browser ECDSA P-256 returns raw 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 when the page is served from HTTPS or localhost. On this HTTP lab URL, the controls use a visible toy signature fallback so students can still test the hash, sign, tamper, wrong-key, and verify flow.
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. On the HTTP lab URL, this panel uses a toy key-agreement fallback so the exchange remains interactive.

How ECDH Works: The Magic Math

Alice

Alice private key preview
Public Key (sent to Bob)

Bob

Bob private key preview
Public Key (sent to Alice)
Shared Secret (Alice/Bob 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 curve equation is:

\[ y^2 = x^3 + ax + b \]

It 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 → the signing key can be recovered

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 = dG \]

Because d is random, Q appears random too — but it is 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 Toy Demo

ECDSA signature math uses a per-signature nonce k. This toy panel exposes the private scalar d, the message hash h, the nonce k, and the signature values r and s so the reuse failure is visible.

Toy private key
Click "Sign Message 1" to create d.
Where k fits
\[ R = kG \]
\[ r = x_R \bmod n \]
\[ s = k^{-1}(h + rd) \bmod n \]
This panel uses a deterministic toy stand-in for r = x(k*G) so the browser can show the algebra without implementing full P-256 point multiplication.
Reuse attack
\[ k = (h_1 - h_2)(s_1 - s_2)^{-1} \bmod n \]
\[ d = (s_1k - h_1)r^{-1} \bmod n \]
Two different messages with the same k expose enough equations to recover both k and d.
h1:
k1:
r1:
s1:
h2:
k2:
r2:
s2:
Lesson: Fresh signatures use different k values, which also produces different r values. Reusing k makes r repeat and lets an observer recover the signing key from public signature data.

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.)