DEV Community: ktaka-ccmp

Implementing ECDSA from Scratch Without Libraries

ktaka-ccmp — Thu, 02 Apr 2026 04:33:06 +0000

Introduction

In the previous article, we used the Web Crypto API's crypto.subtle to sign and verify with ECDSA. The API made it easy, but the internals remained a black box.

In this article, we implement ECDSA signing and verification from scratch using only basic arithmetic and mod — no crypto libraries. We output intermediate values at every step to see exactly what's happening.

The code and explanations in this article were developed through conversation with AI (Claude). The idea of using a small curve to keep all values to two digits, and the structure of showing intermediate values at each step, emerged from that discussion.

Approach: Using a Small Curve

Real ECDSA (P-256) uses 256-bit numbers, but the algorithm is independent of curve size. Here we use y² = x³ + x + 4 (mod 97), a small curve where all values fit in two digits.

const p = 97n;  // Finite field prime
const a = 1n;   // Curve parameter a
const b = 4n;   // Curve parameter b
// Curve: y² = x³ + ax + b (mod p)

The n suffix on number literals denotes JavaScript's BigInt (arbitrary-precision integers).

The Three Layers of ECDSA

ECDSA signing and verification consists of three layers:

Layer	Content	Functions to Implement
1. Modular arithmetic	mod operation, modular inverse	`mod`, `modInverse`
2. Elliptic curve point operations	Point addition, scalar multiplication	`pointAdd`, `scalarMul`
3. ECDSA protocol	Key generation, signing, verification	Combination of above

We'll implement these from the bottom up.

Layer 1: Modular Arithmetic

All ECDSA calculations are performed in the world of modular arithmetic (mod). Two operations are needed: mod and modular inverse.

mod Function

JavaScript's % is a remainder operator that returns negative results for negative inputs (e.g., -1n % 3n → -1n). Using ((a % m) + m) % m ensures the result is always in the range [0, m).

const mod = (a, m) => ((a % m) + m) % m;

Modular Inverse

The modular inverse k⁻¹ is "an integer satisfying k⁻¹ × k ≡ 1 (mod m)," used instead of ordinary division. It can be computed using the Extended Euclidean Algorithm.

const modInverse = (a, m) => {
  a = mod(a, m);
  let [old_r, r] = [a, m];
  let [old_s, s] = [1n, 0n];
  while (r !== 0n) {
    const q = old_r / r;
    [old_r, r] = [r, old_r - q * r];
    [old_s, s] = [s, old_s - q * s];
  }
  if (old_r !== 1n) throw new Error(`No inverse: gcd(${a}, ${m}) = ${old_r}`);
  return mod(old_s, m);
};

For example, modInverse(37n, 97n) returns 21n. Since 37 × 21 = 777 = 97 × 8 + 1, indeed 37 × 21 mod 97 = 1.

How the Extended Euclidean Algorithm works

First, the standard Euclidean algorithm finds the GCD by repeated division. For 37 and 97:

97 = 2 × 37 + 23
37 = 1 × 23 + 14
23 = 1 × 14 +  9
14 = 1 ×  9 +  5
 9 = 1 ×  5 +  4
 5 = 1 ×  4 +  1  ← remainder 1 = GCD
 4 = 4 ×  1 +  0  ← done

Then trace back from remainder 1 to express it as 37 × ? + 97 × ? = 1:

1 = 5 - 1×4
  = 5 - 1×(9 - 1×5)           = 2×5 - 1×9
  = 2×(14 - 1×9) - 1×9        = 2×14 - 3×9
  = 2×14 - 3×(23 - 1×14)      = 5×14 - 3×23
  = 5×(37 - 1×23) - 3×23      = 5×37 - 8×23
  = 5×37 - 8×(97 - 2×37)      = 21×37 - 8×97

So 21 × 37 - 8 × 97 = 1, meaning 37 × 21 ≡ 1 (mod 97). The inverse is 21.

In the code, old_r, r track the remainders, while old_s, s simultaneously compute the "trace-back" coefficients.

Layer 2: Elliptic Curve Point Operations

"Point addition" on an elliptic curve is a geometric operation different from ordinary addition. We also need to handle the point at infinity (identity element).

const INFINITY = { x: null, y: null };
const isInfinity = (P) => P.x === null && P.y === null;

Point Addition P + Q

Draw a line through two points, find the third intersection with the curve, and reflect across the x-axis. When P = Q, use the tangent line (point doubling). The formulas are derived algebraically by solving the line and curve equations simultaneously — they consist only of basic arithmetic, so they work in the mod p world as well. The only difference is that division is replaced by multiplication with the modular inverse, and each result is reduced mod p.

const pointAdd = (P, Q, a, p) => {
  if (isInfinity(P)) return Q;
  if (isInfinity(Q)) return P;
  if (P.x === Q.x && mod(P.y + Q.y, p) === 0n) return INFINITY;

  // lam = slope of the line (tangent slope for point doubling)
  let lam;
  if (P.x === Q.x && P.y === Q.y) {
    // Point doubling: λ = (3x² + a) / (2y)
    lam = mod((3n * P.x * P.x + a) * modInverse(2n * P.y, p), p);
  } else {
    // Addition of two distinct points: λ = (y₂ - y₁) / (x₂ - x₁)
    lam = mod((Q.y - P.y) * modInverse(Q.x - P.x, p), p);
  }
  // Find the third intersection with the curve, then reflect across x-axis
  const xr = mod(lam * lam - P.x - Q.x, p);
  const yr = mod(lam * (P.x - xr) - P.y, p);
  return { x: xr, y: yr };
};

Scalar Multiplication k · P

Adding G to itself k times. A naive loop would be slow, so we use the double-and-add method. For example, k = 42 is 101010 in binary, so 42·G = 32·G + 8·G + 2·G. The algorithm repeatedly doubles G and adds when the corresponding bit is 1. The parameter n is the group order (a value related to the number of points on the curve), computed by findOrder below.

const scalarMul = (k, P, a, p, n) => {
  let result = INFINITY;
  let addend = { ...P };  // doubles each iteration: G, 2G, 4G, 8G, ...
  k = mod(k, n);
  while (k > 0n) {
    if (k & 1n) result = pointAdd(result, addend, a, p);  // add if bit is 1
    addend = pointAdd(addend, addend, a, p);  // double
    k >>= 1n;  // next bit
  }
  return result;
};

Helper Functions

A function to find the order of base point G (n · G = ∞ for the smallest n), and a simple hash function to replace SHA-256:

const findOrder = (G, a, p) => {
  let P = { ...G };
  // By Hasse's theorem, order ≤ p+1+2√p, so p*4 is a safe upper bound
  for (let i = 2n; i < p * 4n; i++) {
    P = pointAdd(P, G, a, p);
    if (isInfinity(P)) return i;
  }
  return null;
};

const toyHash = (msg, n) => {
  let h = 0n;
  for (let i = 0; i < msg.length; i++) {
    h = mod(h * 31n + BigInt(msg.charCodeAt(i)), n);
  }
  return h === 0n ? 1n : h;
};

Curve Parameters and Base Point G

In real P-256, NIST specifies the curve parameters (p, a, b) and the base point G's coordinates in the standard, and each implementation uses those values directly. Here we walk through how the base point is determined, for learning purposes.

Reference: Actual P-256 parameters

p   = 0xFFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF
a   = 0xFFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFC
b   = 0x5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B
G.x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296
G.y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5
n   = 0xFFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551

All values are 256-bit. The scale is vastly different from the toy curve in this article (p=97, n=89), but the algorithm is exactly the same.

Source: NIST SP 800-186 — Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters

Finding Points on the Curve

Substitute x = 0, 1, 2, ... and compute x³ + ax + b mod p, checking whether a y exists such that y² ≡ result (mod p).

x = 0:  x³+x+4 mod 97 =  4  →  y² ≡  4 (mod 97)  →  y = 2, 95   →  (0,2), (0,95)
x = 1:  x³+x+4 mod 97 =  6  →  y² ≡  6 (mod 97)  →  y = 43, 54  →  (1,43), (1,54)
x = 2:  x³+x+4 mod 97 = 14  →  y² ≡ 14 (mod 97)  →  no square root (no point)
x = 3:  x³+x+4 mod 97 = 34  →  y² ≡ 34 (mod 97)  →  no square root (no point)
x = 4:  x³+x+4 mod 97 = 72  →  y² ≡ 72 (mod 97)  →  y = 13, 84  →  (4,13), (4,84)

Points always come in pairs of y and p−y (2 + 95 = 97 = p), symmetric about the x-axis. This curve has 88 points in total (plus the point at infinity ∞).

Choosing a Point with Prime Order

For ECDSA, the order of G (n · G = ∞ for the smallest n) must be prime.

const isPrime = (n) => {
  if (n < 2n) return false;
  for (let d = 2n; d * d <= n; d++) {
    if (n % d === 0n) return false;
  }
  return true;
};

// Search for a point with prime order
for (let x = 0n; x < p; x++) {
  const rhs = mod(x * x * x + a * x + b, p);
  for (let y = 0n; y < p; y++) {
    if (mod(y * y, p) !== rhs) continue;
    const candidate = { x, y };
    const order = findOrder(candidate, a, p);
    if (isPrime(order)) {
      console.log(`G = (${x}, ${y}), order n = ${order}`);
      break;
    }
  }
}

Since the group order is 89 (prime), all 88 points have order 89, and any point can serve as G. We choose G = (0, 2).

Summarizing the curve parameters and base point for this demo:

const p = 97n;
const a = 1n;
const b = 4n;
const G = { x: 0n, y: 2n };

Verification that G is on the curve: 2² mod 97 = 4, 0³ + 1·0 + 4 mod 97 = 4. They match.

Layer 3: ECDSA Protocol

The ECDSA protocol consists of three steps: key generation, signing, and verification.

Key generation:  Compute Q = d · G
                 Recovering d from Q is infeasible (discrete logarithm problem)

Signing:       {d, k, h, (G, a, p, n)}  →  compute (r, s)
Verification:  {Q, s, h', (G, a, p, n)} →  compute r'

d: private key, k: ephemeral key, Q: public key
r, s: signature
h, h': message hash
G, a, p, n: curve parameters

h' == h (no tampering) → r' == r (verification succeeds)
h' ≠ h (tampered)      → r' ≠ r (verification fails)

Why do they arrive at the same r?

Signing and verification each compute the following:

Signing:      R = k·G
              r = R.x mod n
              s = k⁻¹·(h + r·d) mod n
              → signature (r, s)

Verification: R' = s⁻¹·h'·G + s⁻¹·r·Q
              r' = R'.x mod n
              → r' == r means verification succeeds

When h' == h, expanding the verifier's point computation:

R' = s⁻¹·h'·G + s⁻¹·r·Q
   = s⁻¹·h·G + s⁻¹·r·Q       ← substitute h' = h
   = s⁻¹·h·G + s⁻¹·r·(d·G)   ← substitute Q = d·G
   = (s⁻¹·h + s⁻¹·r·d)·G
   = s⁻¹·(h + r·d)·G
   = k·G                       ← from s = k⁻¹·(h+r·d), so s⁻¹·(h+r·d) = k

r' = R'.x mod n
   = (k·G).x mod n
   = r                         ← same as signing side

Therefore, when h' == h, r' == r.

The following code demonstrates each step.

Key Generation

Choose a private key d and compute the public key Q = d · G. d can be any value from 1 to n-1 (1 to 88 for this curve).

// G=(0,2), a=1, p=97 were determined in the previous section
const n = findOrder(G, a, p); // n = 89
const d = 23n;                // Private key (1 ≤ d ≤ n-1)
const Q = scalarMul(d, G, a, p, n); // Public key Q = d · G
console.log(`Private key d = ${d}`);
console.log(`Public key Q = (${Q.x}, ${Q.y})`);

Private key d = 23
Public key Q = (63, 57)

Changing d changes Q:

d = 22  →  Q = (96, 83)
d = 23  →  Q = (63, 57)   ← this demo
d = 24  →  Q = (56, 3)
d = 25  →  Q = (38, 77)

Recovering private key d = 23 from public key Q = (63, 57) is the Elliptic Curve Discrete Logarithm Problem (ECDLP), which becomes computationally infeasible as the curve grows larger.

Signing

Sign a message with private key d to produce the pair (r, s). First, the message is hashed into a numeric value h, then the signature values are computed using an ephemeral key k.

const message = "Hello, ECDSA!";
const h = toyHash(message, n);   // h = 85
const k = 42n;                   // Ephemeral key (use cryptographic random in production)

const R = scalarMul(k, G, a, p, n); // R = (87, 62)
const r = mod(R.x, n);           // r = 87
const kInv = modInverse(k, n);   // k⁻¹ = 53
const s = mod(kInv * (h + r * d), n); // s = 20

console.log(`h = ${h}`);
console.log(`R = (${R.x}, ${R.y})`);
console.log(`k⁻¹ = ${kInv}  (check: ${k} × ${kInv} mod ${n} = ${mod(k * kInv, n)})`);
console.log(`s = ${kInv} × (${h} + ${r} × ${d}) mod ${n} = ${s}`);
console.log(`Signature (r, s) = (${r}, ${s})`);

h = 85
R = (87, 62)
k⁻¹ = 53  (check: 42 × 53 mod 89 = 1)
s = 53 × (85 + 87 × 23) mod 89 = 20
Signature (r, s) = (87, 20)

Note: The ephemeral key k must be freshly generated for each signature. Reusing the same k across different signatures allows an attacker to solve a system of equations and recover the private key d.

Verification

Verify the message using only the public key Q and signature (r, s). The private key d is not needed.

const sInv = modInverse(s, n);          // s⁻¹ = 49
const u1 = mod(h * sInv, n);           // u1 = 71
const u2 = mod(r * sInv, n);           // u2 = 80

const P1 = scalarMul(u1, G, a, p, n);     // P1 = (45, 24)
const P2 = scalarMul(u2, Q, a, p, n);     // P2 = (31, 85)
const Rp = pointAdd(P1, P2, a, p);     // R' = (87, 62)

const valid = !isInfinity(Rp) && mod(Rp.x, n) === r;
console.log(`R' = (${Rp.x}, ${Rp.y})`);
console.log(`R'.x mod n = ${mod(Rp.x, n)},  r = ${r}`);
console.log(`Result: ${valid}`);

R' = (87, 62)
R'.x mod n = 87,  r = 87
Result: true

The x-coordinate of R' matches r. The signature is valid.

Tamper Detection

Changing one character (! → ?) and verifying with the same signature fails.

const tampered = "Hello, ECDSA?";
const hBad = toyHash(tampered, n);        // h' = 26 (original h = 85)

const u1b = mod(hBad * sInv, n);          // u1' = 28
const P1b = scalarMul(u1b, G, a, p, n);
const P2b = scalarMul(u2, Q, a, p, n);       // u2 unchanged
const Rpb = pointAdd(P1b, P2b, a, p);     // R'' = (0, 95)

const validBad = !isInfinity(Rpb) && mod(Rpb.x, n) === r;
console.log(`R'' = (${Rpb.x}, ${Rpb.y})`);
console.log(`R''.x mod n = ${mod(Rpb.x, n)},  r = ${r}`);
console.log(`Result: ${validBad}`);

R'' = (0, 95)
R''.x mod n = 0,  r = 87
Result: false (tampering detected!)

The hash changed from 85 to 26, causing the recovered point's x-coordinate to be 0, which doesn't match r = 87.

Summary

We implemented only four functions: modInverse, pointAdd, scalarMul, and toyHash. These are all that's needed for ECDSA signing and verification.

The base point G is determined by searching for a curve point with prime order, but in production it's fixed by specification and doesn't need to be searched each time. The only difference from real P-256 is the curve parameters and the size of the numbers (256-bit) — the algorithm is exactly the same.

In the previous article, the internals of crypto.subtle.sign() / crypto.subtle.verify() were handled in a single line. In this article, we wrote everything by hand and confirmed what's happening inside the black box.

Full Code

Run the following shell command to save it as ecdsa-from-scratch.mjs. For browsers, paste the JavaScript portion (excluding the cat and EOF lines) into the DevTools Console.

Environment	How to Run
Browser	Paste the JavaScript portion into the DevTools Console
Bun	`bun ecdsa-from-scratch.mjs`
Node.js (v19+)	`node ecdsa-from-scratch.mjs`

cat << 'EOF' > ecdsa-from-scratch.mjs
// ============================================================
// ECDSA from Scratch — No libraries, BigInt only
// Run: node ecdsa-from-scratch.mjs / bun ecdsa-from-scratch.mjs
// ============================================================

// --- Modular arithmetic ---
const mod = (a, m) => ((a % m) + m) % m;

const modInverse = (a, m) => {
  a = mod(a, m);
  let [old_r, r] = [a, m];
  let [old_s, s] = [1n, 0n];
  while (r !== 0n) {
    const q = old_r / r;
    [old_r, r] = [r, old_r - q * r];
    [old_s, s] = [s, old_s - q * s];
  }
  if (old_r !== 1n) throw new Error(`No inverse: gcd(${a}, ${m}) = ${old_r}`);
  return mod(old_s, m);
};

// --- Elliptic curve point operations ---
const INFINITY = { x: null, y: null };
const isInfinity = (P) => P.x === null && P.y === null;

const pointAdd = (P, Q, a, p) => {
  if (isInfinity(P)) return Q;
  if (isInfinity(Q)) return P;
  if (P.x === Q.x && mod(P.y + Q.y, p) === 0n) return INFINITY;
  let lam;
  if (P.x === Q.x && P.y === Q.y) {
    lam = mod((3n * P.x * P.x + a) * modInverse(2n * P.y, p), p);
  } else {
    lam = mod((Q.y - P.y) * modInverse(Q.x - P.x, p), p);
  }
  const xr = mod(lam * lam - P.x - Q.x, p);
  const yr = mod(lam * (P.x - xr) - P.y, p);
  return { x: xr, y: yr };
};

const scalarMul = (k, P, a, p, n) => {
  let result = INFINITY;
  let addend = { ...P };  // doubles each iteration: G, 2G, 4G, 8G, ...
  k = mod(k, n);
  while (k > 0n) {
    if (k & 1n) result = pointAdd(result, addend, a, p);  // add if bit is 1
    addend = pointAdd(addend, addend, a, p);  // double
    k >>= 1n;  // next bit
  }
  return result;
};

// --- Helper functions ---
const findOrder = (G, a, p) => {
  let P = { ...G };
  // By Hasse's theorem, order ≤ p+1+2√p, so p*4 is a safe upper bound
  for (let i = 2n; i < p * 4n; i++) {
    P = pointAdd(P, G, a, p);
    if (isInfinity(P)) return i;
  }
  return null;
};

const toyHash = (msg, n) => {
  let h = 0n;
  for (let i = 0; i < msg.length; i++) {
    h = mod(h * 31n + BigInt(msg.charCodeAt(i)), n);
  }
  return h === 0n ? 1n : h;
};

// --- Curve parameters ---
const p = 97n;
const a = 1n;
const b = 4n;
const G = { x: 0n, y: 2n };
const fmt = (P) => isInfinity(P) ? "∞" : `(${P.x}, ${P.y})`;

// --- Key generation ---
const n = findOrder(G, a, p);
const d = 23n;
const Q = scalarMul(d, G, a, p, n);
console.log(`[Key Generation]`);
console.log(`  Private key d = ${d}`);
console.log(`  Public key Q = d · G = ${fmt(Q)}`);

// --- Signing ---
const message = "Hello, ECDSA!";
const h = toyHash(message, n);
const k = 42n;
const R = scalarMul(k, G, a, p, n);
const r = mod(R.x, n);
const kInv = modInverse(k, n);
const s = mod(kInv * (h + r * d), n);
console.log(`\n[Signing]`);
console.log(`  Message: "${message}"`);
console.log(`  h = ${h}, k = ${k}`);
console.log(`  R = k · G = ${fmt(R)}`);
console.log(`  r = R.x mod n = ${r}`);
console.log(`  k⁻¹ = ${kInv}  (check: ${k} × ${kInv} mod ${n} = ${mod(k * kInv, n)})`);
console.log(`  s = k⁻¹ × (h + r × d) mod n = ${s}`);
console.log(`  Signature (r, s) = (${r}, ${s})`);

// --- Verification ---
const sInv = modInverse(s, n);
const u1 = mod(h * sInv, n);
const u2 = mod(r * sInv, n);
const P1 = scalarMul(u1, G, a, p, n);
const P2 = scalarMul(u2, Q, a, p, n);
const Rp = pointAdd(P1, P2, a, p);
const valid = !isInfinity(Rp) && mod(Rp.x, n) === r;
console.log(`\n[Verification]`);
console.log(`  s⁻¹ = ${sInv}, u1 = ${u1}, u2 = ${u2}`);
console.log(`  R' = u1·G + u2·Q = ${fmt(Rp)}`);
console.log(`  R'.x mod n = ${mod(Rp.x, n)},  r = ${r}`);
console.log(`  Result: ${valid}`);

// --- Tamper detection ---
const tampered = "Hello, ECDSA?";
const hBad = toyHash(tampered, n);
const u1b = mod(hBad * sInv, n);
const P1b = scalarMul(u1b, G, a, p, n);
const P2b = scalarMul(u2, Q, a, p, n);
const Rpb = pointAdd(P1b, P2b, a, p);
const validBad = !isInfinity(Rpb) && mod(Rpb.x, n) === r;
console.log(`\n[Tamper Detection]`);
console.log(`  Tampered message: "${tampered}"`);
console.log(`  h' = ${hBad} (original h = ${h})`);
console.log(`  R'' = ${fmt(Rpb)}`);
console.log(`  R''.x mod n = ${mod(Rpb.x, n)},  r = ${r}`);
console.log(`  Result: ${validBad}`);
EOF

Understanding ECDSA Signatures with the Web Crypto API

ktaka-ccmp — Fri, 27 Mar 2026 22:22:35 +0000

Introduction

Cryptographic techniques are used everywhere on the internet — TLS, SSH, email signatures, and more. Signing, verification, encryption, decryption, key exchange — these terms come up constantly, yet if asked whether I truly understood how they work, the honest answer was: not really.

Then I discovered the Web Crypto API. It's a cryptographic API built into the browser that lets you perform crypto operations without any external libraries. The API is simple enough that you can learn by writing and running code.

This motivated me to properly understand the fundamentals of cryptography at the code level. In this article, we'll look at digital signatures (ECDSA) and see how signing and verification actually work.

What is the Web Crypto API?

The Web Crypto API is a cryptographic API built into the browser. It allows you to perform key generation, signing, verification, encryption, and decryption without any external libraries.

All operations are accessed through the crypto.subtle object.

Method	Purpose
`crypto.subtle.generateKey()`	Generate key pairs or symmetric keys
`crypto.subtle.sign()`	Sign with a private key
`crypto.subtle.verify()`	Verify with a public key
`crypto.subtle.encrypt()`	Encrypt
`crypto.subtle.decrypt()`	Decrypt
`crypto.subtle.deriveKey()`	Derive a symmetric key from key exchange
`crypto.subtle.exportKey()`	Export a key in JWK or other formats
`crypto.subtle.importKey()`	Import an external key

Each method returns a Promise, so you receive results with await. In this article, we'll use three: generateKey, sign, and verify.

Main algorithms available with generateKey:

Algorithm	Type	Purpose
ECDSA	Elliptic curve (P-256, etc.)	Signing and verification
RSA-OAEP	RSA	Encryption and decryption
AES-GCM	Symmetric key	Authenticated encryption/decryption
ECDH	Elliptic curve (P-256, etc.)	Key exchange
HMAC	Symmetric key	Message authentication

The same crypto.subtle is also available in Bun and Node.js (v19+), so the same code runs on the server side as well.

What is a Digital Signature?

A digital signature is a mechanism where you "sign with a private key and verify with a public key." Only the signer can create the signature, but anyone can verify its authenticity.

Operation	Key Used	Meaning
Sign	Private key	Proves that you created it
Verify	Public key	Anyone can confirm authenticity

In this article, we'll use the Web Crypto API to sign and verify with ECDSA (Elliptic Curve Digital Signature Algorithm).

Code: Key Pair Generation → Signing → Verification

Run the following shell command to save the code as ecdsa.mjs. For browsers, paste the JavaScript portion (excluding the cat and EOF lines) into the DevTools Console.

Environment	How to Run
Browser	Paste the JavaScript portion into the DevTools Console
Bun	`bun ecdsa.mjs`
Node.js (v19+)	`node ecdsa.mjs`

cat << 'EOF' > ecdsa.mjs

// 1. Generate key pair (ECDSA, P-256)
const keyPair = await crypto.subtle.generateKey(
  { name: "ECDSA", namedCurve: "P-256" },
  true, // extractable: true to allow key export (use false in production)
  ["sign", "verify"]
);

// 2. Data to sign
const message = "Hello, WebCrypto!";
const data = new TextEncoder().encode(message);

// 3. Sign with private key
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  keyPair.privateKey,
  data
);

// 4. Verify with public key (original data)
const isValid = await crypto.subtle.verify(
  { name: "ECDSA", hash: "SHA-256" },
  keyPair.publicKey,
  signature,
  data
);

// 5. Verify with tampered data
const tamperedMessage = "Hello, WebCrypto! (tampered)";
const tampered = new TextEncoder().encode(tamperedMessage);
const isValidTampered = await crypto.subtle.verify(
  { name: "ECDSA", hash: "SHA-256" },
  keyPair.publicKey,
  signature,
  tampered
);

// Export key pair
const privateKey = await crypto.subtle.exportKey("jwk", keyPair.privateKey);
const publicKey = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Output
console.log("Key pair generated:\nPrivate key:", privateKey);
console.log("Public key:", publicKey);

console.log("\nSigning:\nData:", message);
console.log("Signature (Base64):", btoa(String.fromCharCode(...new Uint8Array(signature))));

console.log("\nVerification:\nData:", message);
console.log("Result:", isValid); // true

console.log("\nTampered data verification:\nData:", tamperedMessage);
console.log("Result:", isValidTampered); // false
EOF

Sample output:

$ bun ecdsa.mjs
Key pair generated:
Private key: {
  crv: "P-256",
  d: "qTk9mKRBkX5MCnNzGeCvg5sO1vAWe0FLRXHse7QzSlQ",
  ext: true,
  key_ops: [ "sign" ],
  kty: "EC",
  x: "lWH4MQwp7VEMqAKxk_DYef1_ZY4lVciws4nj1wwFANE",
  y: "c_aEH9x91cYmuaatRW5Nys6uFHDBadDZA4IJuPLVQCY",
}
Public key: {
  crv: "P-256",
  ext: true,
  key_ops: [ "verify" ],
  kty: "EC",
  x: "lWH4MQwp7VEMqAKxk_DYef1_ZY4lVciws4nj1wwFANE",
  y: "c_aEH9x91cYmuaatRW5Nys6uFHDBadDZA4IJuPLVQCY",
}

Signing:
Data: Hello, WebCrypto!
Signature (Base64): j3z3keEwOxWWl/7kJ9vWphyQYsY/W78TlCB/b0OuN4jlWCAXmWVwOD9DYyk54C3NG/eZblKt6cNYMf6rg24gUw==

Verification:
Data: Hello, WebCrypto!
Result: true

Tampered data verification:
Data: Hello, WebCrypto! (tampered)
Result: false

The code first generates an ECDSA key pair, then signs data with the private key to produce a signature. When verifying the signature using the public key and data, the original data returns true while tampered data returns false. If even a single byte of data changes, the signature verification fails and tampering is detected. Since the signature cannot be forged from the public key alone, a third party can confirm that "the owner of the private key signed this data."

Key Points

ECDSA is for signing only. It cannot encrypt or decrypt. Encryption requires different algorithms.
extractable: false prevents the private key from being exported. This setting is recommended in production.
P-256 (secp256r1) is a widely used curve on the web and mobile. It's also used in TLS, SSH, and Passkeys.

Summary

The Web Crypto API is a cryptographic API built into the browser, making it easy to experiment with code in the browser console, Bun, or Node.js. Using crypto.subtle, we demonstrated the generation and verification of ECDSA digital signatures. We confirmed that the fundamentals of asymmetric cryptography — signing with a private key and verifying with a public key — can be easily tested.

Appendix: What Does ECDSA Actually Compute?

Key Pair Generation:

Generate a random integer d (1 ≤ d ≤ n-1, where n is the curve order) → this is the private key
Compute a point on the elliptic curve: Q = d · G (G is the base point) → this is the public key

The private key is just a random number, and the public key is a point derived from it via scalar multiplication on the elliptic curve. Recovering d from Q and G is extremely difficult, so the private key cannot be derived from the public key.

Signing (private key side):

Hash the data: h = SHA-256(data)
Generate a random number k
Compute a point on the elliptic curve: R = k · G (G is the base point)
r = R.x mod n (x-coordinate of R)
s = k⁻¹ × (h + r × private_key) mod n
The signature is the pair (r, s)

Verification (public key side):

Hash the data: h = SHA-256(data)
u1 = h × s⁻¹ mod n
u2 = r × s⁻¹ mod n
Recover a point on the elliptic curve: R' = u1 · G + u2 · public_key
If R'.x mod n == r, return true

Verification recovers a point on the elliptic curve from the data hash, s from the signature, and the public key, then checks whether its x-coordinate matches r from the signature.

Point Addition and Scalar Multiplication on Elliptic Curves:

k · G is the point obtained by adding the elliptic curve point G to itself k times.

Point addition on elliptic curves is a geometric operation different from ordinary addition.

Point addition (P + Q):

Draw a line through two points P and Q on the curve
Find the third point where the line intersects the curve
Reflect that point across the x-axis → this is P + Q

Point doubling (P + P):

Draw the tangent line at P
Find the point where the tangent intersects the curve
Reflect across the x-axis → this is 2P

Scalar multiplication k · G repeats this addition k times (G + G + G + ... + G). In practice, the "double-and-add" method computes this efficiently.

Why this works as cryptography:

Computing k · G from k and G is fast
Recovering k from G and k · G is extremely difficult (Elliptic Curve Discrete Logarithm Problem)

This one-way property is the foundation of ECDSA's security.

About k⁻¹:

k⁻¹ is the modular inverse of k (an integer satisfying k⁻¹ × k ≡ 1 (mod n)). Unlike ordinary division (1/k), this performs the equivalent of "division" using integers in the mod n world.

For a hands-on implementation of these calculations: Implementing ECDSA from Scratch Without Libraries

References:

Implementing FedCM Login in the oauth2-passkey Rust Library

ktaka-ccmp — Sat, 14 Mar 2026 09:34:58 +0000

FedCM (Federated Credential Management) is a W3C standard API that enables federated authentication through browser-native UI. Instead of popup windows or redirects, the browser itself displays an account chooser and communicates directly with the identity provider.

This article explains how FedCM works, how to implement it, the differences from the traditional OAuth2 Authorization Code Flow, and the security trade-offs involved.

What is FedCM?

FedCM (Federated Credential Management) is an API that performs federated authentication through browser-native UI. No popup windows, no redirects -- the browser itself displays the account chooser.

In the traditional OAuth2 flow, the RP (your app) redirects to Google's page, and after authentication, returns to a callback URL. With FedCM, you simply call navigator.credentials.get(), the browser communicates directly with Google, and returns a JWT ID token.

Traditional OAuth2 Authorization Code Flow:
  Button click -> Popup -> Google auth page
    -> Redirect (with authorization code)
    -> Backend exchanges code with Google (server-to-server)
    -> Obtain ID token -> Validate -> Establish session

FedCM:
  Button click -> navigator.credentials.get()
    -> Browser displays native UI account chooser
    -> Browser obtains JWT ID token directly from Google
    -> JS posts token to backend -> Validate -> Establish session

With FedCM, the browser acts as an intermediary, so JavaScript loaded from the RP cannot see the list of accounts. The browser uses Google's session cookies to display account information in the native UI, and only returns the user's selected result to JavaScript.

FedCM account chooser (browser displays native UI)

Traditional OAuth2 Authorization Code Flow (displays Google auth page in popup window)

Implementation Approach

FedCM is provided as a browser standard API (navigator.credentials.get()). Google recommends using it via the GIS SDK, but since it's a standard API, it can be called directly without the SDK.

The advantage of using the standard API directly is that it requires no library dependencies and makes the internal workings easier to understand. When you understand what's happening and how, troubleshooting becomes much easier.

This article explains how to handle FedCM directly as a standard API, using the implementation in oauth2-passkey as an example.

Frontend Implementation

The FedCM frontend implementation consists of four main steps.

1. Obtaining a Nonce

First, obtain a nonce from the server. This nonce is a single-use value to prevent replay attacks.

const nonceResponse = await fetch('/api/fedcm/nonce');
const nonceData = await nonceResponse.json();
// { nonce: "random string", nonce_id: "cache key" }

2. Calling navigator.credentials.get()

Use the obtained nonce to call the FedCM API.

const credential = await navigator.credentials.get({
    identity: {
        providers: [{
            configURL: 'https://accounts.google.com/gsi/fedcm.json',
            clientId: OAUTH2_CLIENT_ID,
            params: {
                nonce: nonceData.nonce,
                response_type: 'id_token',
                scope: 'email profile openid',
                ss_domain: window.location.origin,
            },
        }],
        mode: 'active',
        context: 'signin',
    },
    mediation: 'required',  // Prevent auto re-authn, always require user interaction
});

The configURL is the URL of Google's FedCM configuration file. The browser fetches this to discover the location of various endpoints. The response_type, scope, and ss_domain in the params object are Google-specific requirements not included in the W3C FedCM specification (discussed later). ss_domain contains the origin of the runtime environment (e.g., https://passkey-demo.ccmp.jp).

mode: 'active' is used when responding to a user button click. It's important that this is placed directly under the identity object.

mediation: 'required' is a parameter to prevent automatic re-authentication. With this setting, the browser always prompts the user to select an account.

3. Sending the Token to the Backend

Send the obtained ID token and nonce_id to the backend.

const response = await fetch('/api/fedcm/callback', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
        token: credential.token,
        nonce_id: nonceData.nonce_id
    })
});

if (response.ok) {
    // Login successful, session cookie set via Set-Cookie header
    window.location.reload();
}

The backend validates this ID token and establishes a session.

4. OAuth2 Fallback

function openPopup() {
    if (isFedCMAvailable()) {
        fedcmLogin().catch(function(err) {
            console.log('FedCM failed, falling back to OAuth2 popup:', err.message);
            openPopupOAuth2();
        });
        return;
    }
    openPopupOAuth2();
}

If FedCM fails (unsupported browser, user closes the dialog, error, etc.), the Promise's .catch() automatically initiates the traditional OAuth2 popup flow.

Backend Implementation

The backend processing consists of five main steps.

1. JWT Validation (signature, iss/aud/exp, nonce)

The ID token received from the frontend is in JWT format and requires signature validation and claim validation.

fn validate_fedcm_token(token: String, nonce_id: String) -> IdInfo {
    // JWT signature validation, aud/iss/exp validation
    let idinfo = verify_idtoken(token, CLIENT_ID);

    // Nonce validation (ensures single use)
    verify_and_consume_nonce(nonce_id, idinfo.nonce);

    idinfo
}

JWT validation verifies the following:

Signature verification: Fetch Google's JWKS (public key set), select the key using the kid in the JWT header, and verify the signature
Claim validation: Verify that iss (issuer), aud (Client ID), and exp (expiration) are correct
Nonce validation: Verify that the nonce claim in the ID token matches the pre-generated value, then delete it from the cache after verification to prevent reuse

The JWT returned by Google's FedCM endpoint is in the same format as the ID token obtained through the Authorization Code Flow. This means existing OAuth2 authentication JWT validation code can be reused as-is.

2. Extracting User Information

Extract user information from the validated ID token.

let user_info = UserInfo {
    email: idinfo.email,
    name: idinfo.name,
    provider_user_id: idinfo.sub,  // Google user ID
};

The IdInfo contains email, name, sub (user ID within the provider), etc., which are extracted for use in subsequent processing.

3. Finding or Creating a User

Search for an account using the provider's user ID, and create a new one if it doesn't exist.

// Search for existing account by provider user ID
let existing_user = db.find_user_by_provider_id(user_info.provider_user_id);

let user_id = match existing_user {
    Some(user) => {
        // Log in with existing user
        user.id
    }
    None => {
        // Create new user
        let new_user = db.create_user(user_info.email, user_info.name);
        db.link_provider(new_user.id, user_info.provider_user_id);
        new_user.id
    }
};

If an existing user is found, use that user ID; if not, create a new one.

4. Creating a Session

Once the user ID is determined, create a session.

fn create_session(user_id: String) -> (String, Headers) {
    // Generate session ID and CSRF token
    let session_id = generate_random_string(32);
    let csrf_token = generate_random_string(32);
    let expires_at = now() + Duration::hours(1);

    // Store session in cache
    let session = Session {
        user_id,
        csrf_token,
        expires_at,
    };
    cache.store(session_id, session, ttl: 24h);

    // Create Set-Cookie header
    let headers = Headers::new();
    headers.set_cookie("session_id", session_id, expires_at);

    (session_id, headers)
}

The session ID is randomly generated and stored in a cache store (such as Redis). The CSRF token is also generated here and stored in association with the session.

5. Returning the Set-Cookie Header

Return the created session cookie to the browser as a Set-Cookie header.

// Return response
return Response {
    status: 200,
    headers: headers,  // Contains Set-Cookie header
    body: json!({ "success": true }),
};

The browser automatically sends this cookie with subsequent requests, maintaining the authenticated state.

Post-authentication user processing (account search/creation, session issuance, login history recording) uses functions common with OAuth2.

Security Considerations

FedCM brings UX improvements, but its security model differs from the traditional OAuth2/OIDC flow.

Aspect	Authorization Code Flow + PKCE	FedCM
ID token acquisition	Server exchanges authorization code	Browser obtains directly
JavaScript-accessible information	Authorization code (worthless)	JWT ID token (usable for authentication)
XSS attack risk	Authorization code alone cannot authenticate	Usable for authentication within validity period

In my understanding, OAuth2 + PKCE has higher resistance to XSS attacks. Note that Google's One Tap (GIS SDK) also adopts the same model.

(If you have different views or additional insights on the security evaluation, I'd appreciate hearing them)

Caveats When Calling FedCM API

The parameters in the JSON object passed to navigator.credentials.get() require the following considerations.

Google-Specific Required Fields

When using Google's FedCM endpoint, the following parameters are required within the params object.

Field	Value	Description
`response_type`	`'id_token'`	Required for Google to return JWT
`scope`	`'email profile openid'`	Requested scopes
`ss_domain`	`window.location.origin`	RP's origin

`mode: 'active'` Placement

FedCM has active mode and passive mode. Active mode responds to user button operations, while passive mode automatically displays on page load.

When using active mode, mode: 'active' must be placed directly under the identity object. If placed inside the provider object, Chrome ignores it and operates in passive mode. No error is shown.

In passive mode, when a user closes the dialog, a cooldown occurs, preventing FedCM from being used for 2 hours to a maximum of 4 weeks. Active mode has no such cooldown. If the placement is wrong, FedCM becomes unusable for a long period just because the user closed the dialog once.

Other Considerations

JSON-wrapped JWT: Google's FedCM endpoint may return the JWT wrapped in JSON like {"token":"eyJ..."}. It's not a raw JWT string, so parsing is required.

Nonce params migration: Starting with Chrome 143, the nonce must be placed inside the params object rather than directly under the provider object. Chrome 145 removed support for the old format.

Browser Support

Browser	Support
Chrome 108+	Supported
Edge 108+	Supported
Safari	Not supported (falls back to popup)
Firefox	Not supported (falls back to popup)

Summary

What became clear through implementing FedCM:

The FedCM frontend is a 3-step process: nonce acquisition → navigator.credentials.get() → POST to backend. Automatically falls back to OAuth2 popup on failure
The backend follows the flow: JWT validation → user info extraction → user search/creation → session creation → Set-Cookie. Existing JWT validation code can be reused as-is
The security model differs from the Authorization Code Flow; OAuth2 + PKCE has higher resistance to XSS attacks. FedCM is a trade-off that prioritizes UX improvement
Parameters for navigator.credentials.get() have Google-specific requirements, and correct notation such as mode: 'active' placement is crucial

See oauth2-passkey for implementation examples. Try the actual behavior at the demo site.

References

Try Passwordless Auth: oauth2-passkey Live Demo

ktaka-ccmp — Sun, 01 Mar 2026 15:12:08 +0000

A live demo of oauth2-passkey, a Rust library that adds OAuth2 and Passkey authentication to your web app with minimal code.

Two short videos below walk through the demo at passkey-demo.ccmp.jp — first registering via Google and adding a Passkey, then signing in using only the Passkey.

Demo 1: Register with Google and Add a Passkey

Here's what happens in the video:

The login page offers two options: "Register / Sign in with Google" and "Sign in with Passkey".
Clicking "Register / Sign in with Google" opens the standard Google account chooser and consent screen.
Immediately after Google authentication, the app prompts: "Create a passkey to sign in?" — this is the Passkey promotion feature, encouraging OAuth2 users to register a Passkey for faster future logins.
After creating the Passkey, the user lands on the Dashboard with links to My Account and Admin Panel.
The My Account page shows User Information, Passkey Credentials, linked OAuth2 Accounts, and Recent Login History.

The key idea: users start with the familiarity of Google sign-in, then immediately gain the speed and security of Passkeys.

Demo 2: Sign in with Passkey

Now the same user signs in again, this time with their Passkey:

On the login page, clicking "Sign in with Passkey" triggers the browser's built-in Passkey dialog.
After biometric verification (fingerprint, face, etc.), the user is logged in instantly — no redirect to Google, no password.
The Login History now shows both the Passkey login and the earlier OAuth2 login, so users can review their full authentication history.

This is the daily login experience: fast, phishing-resistant, and free of external dependencies once the Passkey is registered.

Try It Yourself

Try it now: passkey-demo.ccmp.jp

Sign in with Google, register a Passkey, then sign in with just the Passkey
Explore the admin panel (all demo users get admin access)
View login history with device and authenticator details

Data is stored in memory and resets on server restart, so feel free to experiment.

What is oauth2-passkey?

oauth2-passkey is a Rust library for adding passwordless authentication to web applications. It combines:

OAuth2 (Google) — One-click registration and login, familiar to users
Passkeys (WebAuthn/FIDO2) — Phishing-resistant, biometric login (fingerprint, face, security key)

Users sign up with Google, then optionally add a Passkey for faster daily logins. OAuth2 remains available as a fallback if a device is lost.

Quick Start

Add oauth2-passkey to your Axum application:

use axum::{Router, routing::get, response::IntoResponse};
use oauth2_passkey_axum::{AuthUser, oauth2_passkey_full_router};

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
    oauth2_passkey_axum::init().await?;

    let app = Router::new()
        .route("/", get(home))
        .route("/protected", get(protected))
        .merge(oauth2_passkey_full_router());

    let listener = tokio::net::TcpListener::bind("0.0.0.0:3001").await?;
    axum::serve(listener, app).await?;
    Ok(())
}

async fn home() -> &'static str {
    "Welcome! Visit /o2p/user/login to sign in"
}

async fn protected(user: AuthUser) -> impl IntoResponse {
    format!("Hello, {}!", user.account)
}

The oauth2_passkey_full_router() call adds all authentication routes under /o2p/*, including the login page, OAuth2 flow, Passkey registration and authentication, user account management, and the admin panel.

Set a few environment variables (Google OAuth2 credentials, session secret) and you're ready to go. See the Getting Started guide for details.

Features

Feature	Description
Dual auth	OAuth2 (Google) + Passkeys in one library
Built-in UI	Login page, user account, admin panel
Passkey promotion	Prompts OAuth2 users to register a Passkey
Login history	Records IP, User-Agent, authenticator details
Session management	Secure cookies, conflict policies, force logout
Admin panel	User management, audit trail, admin safeguards
Theme system	9 built-in CSS themes + custom theme support
Storage	SQLite (development) or PostgreSQL (production), with Redis or in-memory caching

Background

This library grew out of a from-scratch Passkey implementation I wrote in early 2025. That project gave me a deep understanding of the WebAuthn protocol, and I decided to package the result into a reusable library with OAuth2 integration, session management, and a complete UI.

DEV Community: ktaka-ccmp

Implementing ECDSA from Scratch Without Libraries

Introduction

Approach: Using a Small Curve

The Three Layers of ECDSA

Layer 1: Modular Arithmetic

mod Function

Modular Inverse

Layer 2: Elliptic Curve Point Operations

Point Addition P + Q

Scalar Multiplication k · P

Helper Functions

Curve Parameters and Base Point G

Finding Points on the Curve

Choosing a Point with Prime Order

Layer 3: ECDSA Protocol

Key Generation

Signing

Verification

Tamper Detection

Summary

Full Code

Understanding ECDSA Signatures with the Web Crypto API

Introduction

What is the Web Crypto API?

What is a Digital Signature?

Code: Key Pair Generation → Signing → Verification

Key Points

Summary

Implementing FedCM Login in the oauth2-passkey Rust Library

What is FedCM?

Implementation Approach

Frontend Implementation

1. Obtaining a Nonce

2. Calling navigator.credentials.get()

3. Sending the Token to the Backend

4. OAuth2 Fallback

Backend Implementation

1. JWT Validation (signature, iss/aud/exp, nonce)

2. Extracting User Information

3. Finding or Creating a User

4. Creating a Session

5. Returning the Set-Cookie Header

Security Considerations

Caveats When Calling FedCM API

Google-Specific Required Fields

mode: 'active' Placement

Other Considerations

Browser Support

Summary

References

Try Passwordless Auth: oauth2-passkey Live Demo

Demo 1: Register with Google and Add a Passkey

Demo 2: Sign in with Passkey

Try It Yourself

What is oauth2-passkey?

Quick Start

Features

Links

Background

`mode: 'active'` Placement