يوسف

What is gnark? (video series)

Mon, 07 Sep 2026 00:00:00 +0000

Season 2 of Linea Insights is a nine-episode series in which I answer one question per episode about gnark, the zero-knowledge proof library we build at Consensys and that powers the Linea zkEVM.

The full playlist is on the Linea YouTube channel.

Cofactor-torsion attacks on hinted scalar multiplications in SNARK circuits

Mon, 24 Aug 2026 00:00:00 +0000

A latent bug in optimized Fp2 square-root algorithms

Mon, 20 Jul 2026 00:00:00 +0000

TL;DR

Three widely-deployed $F_{p^2}$ square-root algorithms — the Adj–Rodríguez “complex method” (ePrint 2012/685, §V-A / Algorithm 8), Scott’s Tricks of the Trade §6.3 (ePrint 2020/1497), and the SQIsign-optimized variant of Aardal et al. (ePrint 2024/1563, Algorithm 3) — silently return $(0, 0)$ on inputs of shape $(a, 0)$ where $a \in F_p$ is a quadratic non-residue. The input is, in fact, always a square in $F_{p^2}$ for any nonzero $a \in F_p$ (Euler’s criterion: $a^{(q^2 - 1)/2} = (a^{q-1})^{(q+1)/2} = 1$), and the correct root is $(0, \sqrt{a/\beta})$ where $\beta = u^2$ is the QNR defining $F_{p^2}$. The algorithms just don’t find it.

The omission is at the paper level, not in any particular library: the proofs in §V-A of Adj–Rodríguez carry an unstated precondition $b \neq 0$. Scott’s exposition inherits it. Aardal et al.’s further optimization fuses away the explicit $\alpha = -1$ branch from a different, correct algorithm in the same Adj–Rodríguez paper (Algorithm 9), losing the protection.

Any library implementing any of the three algorithms verbatim inherits the bug.

1. Square roots in $F_p$

Let $p$ be a large odd prime and $F_p = \mathbb{Z}/p\mathbb{Z}$. For $a \in F_p^*$, computing $\sqrt{a}$ reduces to a single exponentiation in $F_p$ plus an $O(1)$ correction, with the exact form depending on $p \bmod 4$ (or $\bmod 8$, $\bmod 16$):

1.1. The easy case: $p \equiv 3 \pmod 4$

$$ y = a^{(p+1)/4} $$

Check:

$$ y^2 = a^{(p+1)/2} = a \cdot a^{(p-1)/2} = a \cdot \left(\tfrac{a}{p}\right). $$

If $a$ is a QR, $\left(\frac{a}{p}\right) = 1$ and $y^2 = a$. If $a$ is a QNR, $y^2 = -a$ (so the function “computes a sqrt of $-a$ instead”; the caller must check by squaring).

Cost: one $F_p$ exponentiation of bitlength roughly $\log_2 p$, i.e. about $1.5 \log_2 p$ $F_p$ multiplications via square-and-multiply, or fewer via addition chains.

1.2. The general case: Tonelli–Shanks

For $p \equiv 1 \pmod 4$, write $p - 1 = 2^s \cdot q$ with $q$ odd. Tonelli–Shanks finds $\sqrt{a}$ via a precomputed non-residue and $O(s^2)$ $F_p$ multiplications on top of one $F_p$ exponentiation. It’s still dominated by the exp, just with a $(\log_2 p)$-bit exponent and a small bookkeeping tail.

Variants: Atkin’s algorithm (for $p \equiv 5 \pmod 8$), Müller’s algorithm, and Cipolla–Lehmer (variable time). All amount to “one $F_p$ exp + bookkeeping”.

1.3. Cost summary

For any of these algorithms, the dominant cost is one $F_p$ exponentiation with an exponent the size of $p$. We’ll write this as a single unit $M_q$ (one exponentiation in the field of order $q$). Everything else is in the noise. Note the algorithm also tells us whether $a$ is a QR — either by inspecting the post-exp Legendre symbol or by squaring the result and comparing.

2. Square roots in $F_{p^2}$ — the naive approach

The same algorithms transfer directly: if $q = p^2$ is the order of $F_{p^2}$, then for $a \in F_{p^2}^*$, $\sqrt{a}$ is a single $F_{p^2}$ exponentiation away (with the same $\bmod 4 / \bmod 8 / \bmod 16$ casework on $q$, which depends on $p \bmod \cdot$).

Naive cost: one $F_{p^2}$ exponentiation $\approx \log_2(q^2) \cdot 3 = 6 \log_2 p$ $F_p$ multiplications (square-and-multiply with Karatsuba $F_{p^2}$ mul costing 3 $F_p$ muls). That’s a $\sim 3\times$ slowdown vs. $F_p$ Sqrt, because the exponent doubled in bitlength ($\log_2 q^2 = 2 \log_2 p$) and each step cost $\sim 3\times$ more (each $F_{p^2}$ mul $\approx 3$ $F_p$ muls).

So $F_{p^2}$ Sqrt by the naive method is feasible but costly — and pairing libraries do it a lot (G2 point decompression, hash-to-curve, twist arithmetic).

3. The descent: Adj–Rodríguez’s complex method (ePrint 2012/685, §V-A)

Adj and Rodríguez-Henríquez (2012) observed that $\sqrt{a}$ in $F_{p^2}$ can be reduced to two square roots in $F_p$ plus a handful of $F_p$ operations, by exploiting the structure of $F_{p^2} = F_p[u]/(u^2 - \beta)$ for a fixed QNR $\beta \in F_p$. The construction is the “complex method”, named because it generalizes the classical

$$ \sqrt{a + bi} = \sqrt{\frac{a + \sqrt{a^2 + b^2}}{2}} ;+; i \cdot \frac{b}{2 \sqrt{(a + \sqrt{a^2 + b^2})/2}} $$

formula from $\mathbb{C} = \mathbb{R}[i]/(i^2 + 1)$.

3.1. The setup

Let $x = a + b u \in F_{p^2}$ with $a, b \in F_p$ and $u^2 = \beta$ (the defining QNR). Suppose $y = c + d u$ is a square root of $x$, i.e. $y^2 = x$. Expanding:

$$ y^2 = (c + du)^2 = c^2 + 2cd,u + d^2 u^2 = (c^2 + \beta d^2) + (2cd),u. $$

Matching coefficients with $x$:

$$ c^2 + \beta d^2 = a, \qquad 2cd = b. \tag{$\star$} $$

3.2. The norm trick

Take the field norm of both sides of $y^2 = x$:

$$ N(y^2) = N(y)^2 = N(x), $$

where $N(z) = z \cdot z^p = z \cdot \bar z = (\Re z)^2 - \beta (\Im z)^2 \in F_p$ is the $F_p$-valued norm map. So if we compute

$$ s := \sqrt{N(x)} \quad \text{(a single $F_p$ Sqrt — one $F_p$ exp)} $$

then $s = \pm N(y) = \pm(c^2 - \beta d^2)$ (note the sign — minus $\beta$, not plus $\beta$; this is the norm of $y$, not of $y^2$).

3.3. Recovering $c$ and $d$

Now we have two equations involving $c$, $d$:

$$ \begin{aligned} c^2 + \beta d^2 &= a \quad \text{(from $\Re$ of $y^2 = x$)} \ c^2 - \beta d^2 &= \pm s \quad \text{(from $N(y) = \pm s$)} \end{aligned} $$

Adding: $2c^2 = a \pm s$, so $c^2 = (a \pm s)/2$. Subtracting: $2\beta d^2 = a \mp s$, so $d^2 = (a \mp s)/(2\beta)$.

Either of $c$ or $d$ can be recovered with one more $F_p$ Sqrt:

$$ c = \sqrt{(a + s)/2} \quad \text{(one $F_p$ Sqrt — the second $F_p$ exp)}, \qquad d = \frac{b}{2c} \quad \text{(one $F_p$ inv + one $F_p$ mul, from $2cd = b$).} $$

The sign of $s$ is resolved by checking which of $(a + s)/2$ or $(a - s)/2$ is a QR in $F_p$ — one of them is guaranteed to be, by a parity argument: their product is

$$ \frac{(a + s)(a - s)}{4} = \frac{a^2 - s^2}{4} = \frac{a^2 - N(x)}{4} = \frac{a^2 - (a^2 - \beta b^2)}{4} = \frac{\beta b^2}{4}, $$

and $\beta$ is a QNR so $\beta b^2 / 4$ is (QNR)$\cdot$(square) = QNR. Hence one of the two factors must be QR and the other QNR.

3.4. The algorithm (Adj–Rodríguez §V-A “Algorithm 8”)

Algorithm 8 (Adj-Rodríguez "Complex Method"):
Input: x = a + b·u ∈ Fp²*
Output: y ∈ Fp² s.t. y² = x, or ⊥
1: if b = 0:
2: return (√a, 0) ← the bug lives here
3: end if
4: α ← a² − β·b² (= N(x))
5: γ ← χ(α) (Legendre symbol of α in Fp)
6: if γ = −1:
7: return ⊥ (x is not a square in Fp²)
8: end if
9: s ← √α (1st Fp Sqrt)
10: δ ← (a + s) / 2
11: if δ is QNR in Fp: δ ← (a − s) / 2
12: c ← √δ (2nd Fp Sqrt)
13: d ← b / (2c) (1 Fp inv, 1 Fp mul)
14: return (c, d)

Cost: $2 M_q + O(1)$ $F_p$ muls/inverses $\approx 2$ $F_p$ Sqrts. That’s a $\sim 3\times$ speedup vs. naive $F_{p^2}$ Sqrt (which costs $\sim 6$ $F_p$ exps’ worth).

4. The bug: lines 1–2

The purely-real shortcut “if $b = 0$: return $(\sqrt{a}, 0)$” is wrong when $a$ is a non-residue in $F_p$.

4.1. The math

Why $(a, 0)$ is always a square in $F_{p^2}$ for any nonzero $a \in F_p$:

$$ \begin{aligned} (a, 0)^{(q^2 - 1)/2} &= a^{(q^2 - 1)/2} \ &= a^{(q - 1)(q + 1)/2} \ &= \bigl(a^{q - 1}\bigr)^{(q + 1)/2} \ &= 1^{(q + 1)/2} \ &= 1 \qquad \text{(Fermat: $a^{q - 1} = 1$ in $F_p^*$).} \end{aligned} $$

So $(a, 0)$ must have a square root in $F_{p^2}$ — and we even know where it lives. From the equations $(\star)$ of §3.1 with $b = 0$:

$$ c^2 + \beta d^2 = a, \qquad 2cd = 0 ;\Longrightarrow; c = 0 \text{ or } d = 0. $$

$d = 0$ branch: $c^2 = a$. Works iff $a$ is a QR in $F_p$. Yields $(\sqrt{a}, 0)$.
$c = 0$ branch: $\beta d^2 = a$, so $d^2 = a/\beta$. Works iff $a/\beta$ is a QR in $F_p$. Yields $(0, \sqrt{a/\beta})$.

The two branches are complementary by Euler:

$$ \left(\tfrac{a/\beta}{p}\right) = \left(\tfrac{a}{p}\right) \cdot \left(\tfrac{1/\beta}{p}\right) = \left(\tfrac{a}{p}\right) \cdot \left(\tfrac{\beta}{p}\right) = \left(\tfrac{a}{p}\right) \cdot (-1) = -\left(\tfrac{a}{p}\right) $$

(since $\beta$ is QNR by construction). So exactly one of ${a, a/\beta}$ is a QR. If $a$ is QR, the $d = 0$ branch gives the real root. If $a$ is QNR, the $c = 0$ branch gives the purely imaginary root $(0, \sqrt{a/\beta})$. The output is always nonzero.

4.2. Why Algorithm 8 misses it

Line 2 unconditionally returns $(\sqrt{a}, 0)$. When $a$ is QNR, $\sqrt{a}$ doesn’t exist in $F_p$. What the $F_p$ Sqrt routine actually returns depends on the implementation:

Some return $\bot$ / None, in which case the call site propagates $\bot$, claiming $x$ is not a square — wrong, since it is.
Most pairing libraries’ $F_p$ Sqrt returns the exponentiation $a^{(p+1)/4}$ (for $p \equiv 3 \pmod 4$) without checking, yielding a value $r$ such that $r^2 = -a$ rather than $r^2 = a$. The caller sees $(r, 0)$ and may treat it as a sqrt, which it isn’t.
Constant-time variants using ccopy / fp_select cascades based on is_zero silently produce $(0, 0)$, also wrong.

The “proof” given on page 15 of Adj–Rodríguez — that one of $(a + s)/2$, $(a - s)/2$ is a QR because their product is the QNR $\beta b^2 / 4$ — fails when $b = 0$: the product collapses to $0$, which is neither QR nor QNR. The proof has an unstated precondition $b \neq 0$ that the algorithm’s “if $b = 0$” shortcut acknowledges in form but mishandles in substance.

4.3. The right way to handle $b = 0$

The correct branch dispatches on $\left(\frac{a}{p}\right)$:

if b = 0:
if Legendre(a) = +1: return (√_Fp(a), 0) ← purely-real root
else: return (0, √_Fp(a/β)) ← purely-imaginary root

Three $F_p$ operations more than the buggy version (one Legendre symbol, one $F_p$ inv, one $F_p$ Sqrt that runs on a known-QR input). Adding this branch is the fix that gnark-crypto kb8, SQIsign, relic, and (in this writeup’s companion PR) constantine apply.

Adj–Rodríguez had this branch in their own paper — in Algorithm 9, the novel $q \equiv 3 \pmod 4$ algorithm (see §7) — but their Algorithm 8 in §V-A doesn’t, and that’s the one downstream libraries copy.

5. Scott’s inverse-sqrt optimization (ePrint 2020/1497, §6.3)

Michael Scott’s 2020 Tricks of the Trade expands on Adj–Rodríguez’s complex method by fusing the final $F_p$ inversion $d = b/(2c)$ into the second $F_p$ Sqrt via the inverse-square-root trick. Concretely, replace lines 12-13 of Algorithm 8 with:

12': r ← invsqrt(δ) (= 1/√δ; computed via a single Fp exp)
13': c ← r · δ (= √δ)
14': d ← b · r / 2 (= b/(2·√δ) = b/(2c))

The trick: $\mathrm{invsqrt}(\delta) = \delta^{(p-3)/4}$ for $p \equiv 3 \pmod 4$. Computing both $c$ and $d$ from $r$ saves the standalone inversion. Combined with progenitor tricks (Scott’s other contribution), the total cost drops from $\sim 2 M_q + 1$ inv to $\sim 1.5 M_q$.

Scott inherits the bug

Scott’s exposition reads:

If $a + i b$ is a quadratic residue, then one of $(a + \sqrt{a^2 - \beta b^2})/2$ or $(a - \sqrt{a^2 - \beta b^2})/2$ will be a quadratic residue in $F_p$. And indeed this must be the case since their product is equal to $\beta b^2/4$. This is a QNR times a perfect square, and hence a QNR. If a QNR is the product of two other field elements then one of them must be a QR, and the other a QNR. Therefore $\ldots$

Same reasoning, same gap: the “their product is $\beta b^2 / 4$, a QNR” argument requires $b \neq 0$. With $b = 0$ the product is $0$, neither QR nor QNR, and the QNR-times-square argument collapses. Scott §6.3 doesn’t discuss the case at all.

The resulting algorithm has the same shape as Algorithm 8 — same “if $b = 0$” shortcut, same lack of $\left(\frac{a}{p}\right)$-conditional handling. The Scott optimization speeds up the body of Algorithm 8 without revisiting the precondition Algorithm 8 was tacitly resting on.

Result: every library that ports Scott §6.3 has the bug. This includes arkworks-algebra (which patched it locally with an explicit if self.c1.is_zero() { ... } branch citing the Adj–Rodríguez paper’s Algorithm 8), relic’s $p \not\equiv 3 \pmod 4$ branch (which has an explicit purely-real handler), and historically gnark-crypto’s main internal/fptower/e2.go for all six pairing curves (which still has the bug at the time of writing).

6. Aardal et al.’s SQIsign optimization (ePrint 2024/1563, Algorithm 3)

Aardal, Adj, Alblooshi, Aranha, Canales-Martínez, Chávez-Saab, Filho, Reijnders and Rodríguez-Henríquez (2024) further specialized the Scott-optimized algorithm for the SQIsign post-quantum signature scheme, where $p \equiv 3 \pmod 4$. Their Algorithm 3 inlines the $q \equiv 3 \pmod 4$ casework, replaces the final inversion with a partial exponentiation, and reduces the entire computation to two $F_p$ exponentiations with no standalone inversions:

Algorithm 3 (Aardal et al., q ≡ 3 mod 4):
Input: a = (a₀, a₁) ∈ Fp²*
Output: x s.t. x² = a, deterministic and constant-time
1: δ ← (a₀² + a₁²)^((p+1)/4) (one Fp exp)
2: x₀ ← a₀ + δ
3: t₀ ← 2 · x₀
4: x₁ ← t₀^((p−3)/4) (second Fp exp; inverse-sqrt of t₀)
5: x₀ ← x₀ · x₁ (= √x₀ · scale)
6: x₁ ← a₁ · x₁
7: t₁ ← (2 · x₀)²
8: if t₁ = t₀: return (x₀, x₁)
9: else: return (x₁, −x₀)

Steps 8-9 are a clever sign-correction trick: only one of the two pairs $(x_0, x_1)$ or $(x_1, -x_0)$ is the true sqrt, and the test $t_1 = t_0$ picks the right one without an extra exponentiation. With $\beta = -1$ (the SQIsign / BN254 / BLS12-381 setting), the algorithm runs entirely in $F_p$ with two $F_p$ exponentiations and a handful of $F_p$ muls. Beautifully tight.

6.1. Where the bug returns

Algorithm 3 has no “if $b = 0$” shortcut at all — Aardal et al. fused the case-split into the generic path. The intent is to make the algorithm branchless and constant-time. The effect is to remove the only check that might have stopped the bug at the front door.

Trace Algorithm 3 with $a = (a_0, 0)$, $a_0$ non-QR in $F_p$, $p \equiv 3 \pmod 4$:

Step 1. Compute $\delta$:

$$ \delta = (a_0^2 + 0)^{(p+1)/4} = a_0^{(p+1)/2} = a_0 \cdot a_0^{(p-1)/2} = a_0 \cdot \left(\tfrac{a_0}{p}\right) = a_0 \cdot (-1) = -a_0. $$

Step 2. Compute $x_0 = a_0 + \delta = a_0 + (-a_0) = 0$. This is where the bug fires.

Steps 3–7. Cascade through zero:

$$ t_0 = 0, \quad x_1 = 0^{(p-3)/4} = 0, \quad x_0 \leftarrow x_0 \cdot x_1 = 0, \quad x_1 \leftarrow a_1 \cdot x_1 = 0, \quad t_1 = (2 \cdot 0)^2 = 0. $$

Step 8. $t_1 = t_0$ (both zero), so return $(x_0, x_1) = (0, 0)$.

The output is $(0, 0)$, but the correct answer is $(0, \sqrt{a_0/\beta}) = (0, \sqrt{-a_0})$ (for $\beta = -1$), which exists in $F_p$ because $-1$ is QNR (so $-a_0 = (-1) \cdot \text{non-QR} = \text{QR}$) and is in the SQIsign codomain.

6.2. Why fusing broke things

Adj–Rodríguez 2012/685 actually has a bug-free algorithm for $q \equiv 3 \pmod 4$ — their Algorithm 9, presented in §V-B. It explicitly tests $\alpha = \left(\frac{x}{F_{p^2}}\right)$ (computed cheaply as $\alpha = a^{(q-1)/2}$) and handles the $\alpha = -1$ case via $x \leftarrow i \cdot x_0$ where $i = \sqrt{-1} \in F_{p^2}$ (which exists because $q \equiv 3 \pmod 4 \Rightarrow -1$ is QNR in $F_p \Rightarrow i \notin F_p$ but $i \in F_{p^2}$).

The $\alpha = -1$ branch is exactly the case where the input has its $F_{p^2}$-Legendre symbol equal to $-1$ only because the imaginary root is in $F_{p^2} \setminus F_p$ — i.e., the purely-real-non-QR-input case. Algorithm 9 catches it; Algorithm 3 fuses it away.

Aardal et al. mention that they’re building on Adj–Rodríguez §V (Algorithms 8, 9, 10), but the “fusion” pattern they pursue ends up moving from the structure of Algorithm 9 (which has the $\alpha = -1$ branch) back toward the structure of Algorithm 8 (which doesn’t). The optimization’s appeal is the absence of branches — but the absent branch is the one keeping correctness.

Result: every library that ports Aardal Algorithm 3 verbatim has the bug. The fix is to add a guard that detects the collapse (e.g., “if $a_1 = 0$ then $\delta \leftarrow a_0$” overrides the bad $\delta = -a_0$) or to switch back to Algorithm 9’s $\alpha = -1$ test. SQIsign’s own reference C implementation does the guard (fp_select(&x0, &x0, &(a->re), fp_is_zero(&(a->im))) at src/gf/ref/lvlx/fp2.c:162). Relic does the same (fp_copy_sec(t[0], a[0], fp_is_zero(a[1]))). gnark-crypto and constantine’s BLS12-377 path inherited the bug raw, and were patched only after independent rediscovery.

7. The fix: Adj–Rodríguez’s own Algorithm 9

The bug-free recipe has been in the same 2012 paper the whole time. Algorithm 9 (Adj–Rodríguez §V-B):

Algorithm 9 (Adj-Rodríguez, q ≡ 3 mod 4):
Input: a ∈ Fp²*, i ∈ Fp² with i² = −1
Output: x s.t. x² = a, or ⊥
1: a₁ ← a^((q − 3)/4) (one Fp² exp)
2: α ← a₁ · (a₁ · a) (= a^((q−1)/2) ∈ Fp²)
3: a₀ ← α · α^q (= α^(q+1); Legendre check)
4: if a₀ = −1: return ⊥ (a is not a square in Fp²)
5: x₀ ← a₁ · a (= a^((q+1)/4))
6: if α = −1: ★ KEY BRANCH
7: return i · x₀ (purely-imaginary root)
8: else:
9: b ← (1 + α)^((q − 1)/2) (Tonelli-style correction)
10: return b · x₀
11: end if

The $\alpha = -1$ branch is the structural fix the optimization layers fuse away. Adj–Rodríguez Algorithm 9 is the only one of the algorithms discussed here that handles the purely-real non-QR input correctly without an explicit “if $b = 0$” guard — because the guard is implicit in the $\alpha = -1$ test.

The Rust implementation zkcrypto/bls12_381’s Fp2::sqrt ports Algorithm 9 directly (citing it by name in the source comment: // Algorithm 9, https://eprint.iacr.org/2012/685.pdf, with constant time modifications.). It has been bug-free since the crate’s first release in $\sim 2020$. blst uses a different but equivalent rotation-alignment trick that also catches the case structurally. arkworks-algebra ports Algorithm 8 but adds the if c1.is_zero() branch with explicit Legendre dispatch (the §4.3 fix above).

For libraries that ship Algorithm 8 / Scott §6.3 / Aardal Algorithm 3 in their pristine published form, the bug is silent until a caller happens to ask for $\sqrt{(\text{non-QR}, 0)}$. That hardly ever happens in mainstream pairing protocols (curve constants block it), so the bug has lain dormant. But it’s directly reachable from any code that constructs primitive cube roots of unity in $F_{p^2}$ (via $(\sqrt{-3} - 1)/2$), Frobenius endomorphism constants, or post-quantum isogeny intermediates — that’s how it got rediscovered three times in the last three years.

8. Provenance summary

Adj-Rodríguez 2012/685 Algorithm 8 ──► buggy (purely-real shortcut)
│
▼
Scott 2020/1497 §6.3 ──► buggy (inherits the §V-A proof gap)
│
▼ (fused via Aardal optimization)
Aardal 2024/1563 Algorithm 3 ──► buggy (re-introduces by absorbing α-detection)
Adj-Rodríguez 2012/685 Algorithm 9 ──► CORRECT (q ≡ 3 mod 4, has the α = −1 branch)
│
└─► zkcrypto/bls12_381 Fp2::sqrt ──► clean (since ~2020)
Adj-Rodríguez 2012/685 Algorithm 10 ──► CORRECT (q ≡ 1 mod 4)

9. Impact

It turns out that libraries that implement the faster algorithms are the ones impacted:

gnark-crypto: https://github.com/Consensys/gnark-crypto/pull/845
Constantine: https://github.com/mratsim/constantine/pull/620
Relic: commit1, commit2, commit3

10. References

Gora Adj, Francisco Rodríguez-Henríquez. Square root computation over even extension fields. IACR ePrint 2012/685. https://eprint.iacr.org/2012/685
Michael Scott. A note on the calculation of some functions in finite fields: Tricks of the Trade. IACR ePrint 2020/1497, §6.3. https://eprint.iacr.org/2020/1497
Aardal et al. Optimized One-Dimensional SQIsign Verification on Intel and Cortex-M4. IACR ePrint 2024/1563, Algorithm 3. https://eprint.iacr.org/2024/1563

Divide-and-Pair SMT for gnark-crypto Twisted Edwards Curves

Mon, 20 Jul 2026 00:00:00 +0000

This note summarizes the subgroup-membership test (SMT) induced by the divide-and-pair framework (https://eprint.iacr.org/2026/749) for the twisted Edwards curves currently present in gnark-crypto.

Main rule

Let $E/\mathbb{F}_p$ be a twisted Edwards curve with group order $h \cdot r$, where $r$ is prime and $h$ is a small power of $2$.

The divide-and-pair SMT depends on:

whether $h \mid (p - 1)$, which determines whether the relevant Tate pairing is already non-degenerate over $\mathbb{F}_p$;
whether the rational small torsion is cyclic or split.

For $E/\mathbb{F}_p: ax^2+y^2=1+dx^2y^2$, the rational $2$-torsion is:

cyclic if $\text{Legendre}(ad) = -1$;
split if $\text{Legendre}(ad) = +1$.

Why this works:

$E$ is birational over $\mathbb{F}_p$ to the Montgomery curve $B y^2 = x^3 + A x^2 + x$ with $A = \frac{2(a+d)}{a-d}, \qquad B = \frac{4}{a-d}.$
The rational $2$-torsion on the Montgomery model is determined by the roots of $x^3 + A x^2 + x = x(x^2 + A x + 1).$
One $2$-torsion point is always rational, namely $x = 0$.
The other two $2$-torsion points are rational iff $x^2 + A x + 1$ splits over $\mathbb{F}_p$, i.e. iff its discriminant $A^2 - 4$ is a square in $\mathbb{F}_p$.
Using $A = 2(a+d)/(a-d)$, we get $A^2 - 4 = \frac{16ad}{(a-d)^2}.$
Since $16$ and $(a-d)^2$ are squares, $A^2 - 4$ is a square iff $ad$ is a square.

Therefore:

$\text{Legendre}(ad) = -1$ means there is only one rational nonzero $2$-torsion point, so the rational $2$-primary torsion is cyclic;
$\text{Legendre}(ad) = +1$ means the full rational $2$-torsion is split, so the rational $2$-primary torsion has rank $2$.

Equivalently:

if $\text{Legendre}(ad) = -1$ and $h = 8$, then $E(\mathbb{F}_p) \cong \mathbb{Z}/(8r)$;
if $\text{Legendre}(ad) = -1$ and $h = 4$, then $E(\mathbb{F}_p) \cong \mathbb{Z}/(4r)$;
if $\text{Legendre}(ad) = +1$ and $h = 4$, then $E(\mathbb{F}_p) \cong \mathbb{Z}/(2r) \times \mathbb{Z}/2$.

In all gnark-crypto twisted Edwards companion curves, $h \mid (p - 1)$ always because $p$ is the subgroup order $r$ of the SNARK curve chosen s.t. a high power of $2$ divides $r-1$, so no $\mathbb{F}_{p^2}$ extension is needed.

Curves

Curve	Cofactor	$v_2(p-1)$	$\text{Legendre}(ad)$	Rational structure	Divide-and-pair SMT
BN254 (baby-jubjub)	8	28	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing
bls12-377	4	47	$-1$	$\mathbb{Z}/(4r)$	$0$ halvings, $1$ degree-$4$ pairing
bls12-381 (Jubjub)	8	32	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing
bls12-381 (bandersnatch)	4	32	$+1$	$\mathbb{Z}/(2r) \times \mathbb{Z}/2$	$0$ halvings, $2$ degree-$2$ pairings
bls24-315	8	22	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing
bls24-317	8	60	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing
bw6-633	8	20	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing
bw6-761	8	46	$-1$	$\mathbb{Z}/(8r)$	$0$ halvings, $1$ degree-$8$ pairing

Consequences

All cofactor-$8$ companion Edwards curves in gnark-crypto admit the most favorable base-field divide-and-pair SMT: a single degree-$8$ Tate pairing, equivalently an octic residuosity check on a precomputed Miller value.
BLS12-377 similarly admits a single degree-$4$ pairing check.
Bandersnatch is different: its rational $2$-torsion is split, so SMT requires two independent degree-$2$ checks. This matches the existing gnark-crypto implementation, which uses two Legendre-symbol tests: https://hackmd.io/@yelhousni/tate-subgroup.
Since the base field already gives non-degeneracy for the relevant $2$-power torsion, extending to $\mathbb{F}_{p^2}$ would not simplify SMT for any of these curves.
In all cases present in gnark-crypto the Divide-and-Pair SMT reduces to the Koshelev test.
Code in: https://github.com/Consensys/gnark-crypto/pull/833

On the Security of Constraint-Friendly Map-to-Curve Relations

Wed, 27 May 2026 00:00:00 +0000

Standard hash-to-curve constructions first hash the message to a field element through a cryptographic hash-to-field step, then map this field element to an elliptic-curve point. Inside constraint systems, this inner cryptographic hash is often the dominant cost. Groth, Malvai, Miller and Zhang (Asiacrypt 2025) introduced constraint-friendly map-to-elliptic-curve-group relations that bypass this step, achieving substantial reductions in circuit size. Their security proof works in the Elliptic Curve Generic Group Model (EC-GGM).

We identify three gaps. First, the security bound in terms of the message space size $M$ and tweak bound $T$ is not explicitly analyzed, and the bounds stated for the concrete instantiations are loose. Second, the EC-GGM does not capture the algebraic structure of most deployed curves; we exhibit a concrete signature forgery using the parameters claimed secure. Third, the construction requires a congruence condition on the field that is not satisfied by all deployed curves; we extend it to any field.

As a countermeasure we propose a $y$-increment variant that neutralizes the algebraic attack, removes the field restriction, and preserves a comparable constraint count. We implement and benchmark both constructions in the open-source gnark (Go) library; the attack is additionally demonstrated via a self-contained SageMath simulation and confirmed at the circuit level against the authors’ own Noir (Rust) implementation.

Divide-and-Pair: Faster subgroup membership testing for elliptic curves

Tue, 21 Apr 2026 00:00:00 +0000

On the Security of Constraint-Friendly Map-to-Curve Relations

Wed, 25 Mar 2026 00:00:00 +0000

Fast cube roots in Fp2 via the algebraic torus

Wed, 25 Feb 2026 00:00:00 +0000

Zero-Knowledge Proofs — The Bridge Between Cryptographic Theory and Blockchain Scalability

Thu, 15 Jan 2026 00:00:00 +0000

بين المفتاح والملكية و التحفيظ: تأمل في شرعية الأرض والانتماء

Mon, 10 Nov 2025 00:00:00 +0000

صادف تواجدي بالمغرب الأسبوع الماضي احتفال المغاربة بقرار أممي يرسخ مقترح الحكم الذاتي كحل واقعي لقضية الصحراء، وكأن العالم استيقظ لتوكيد ما عرفناه نحن المغاربة منذ أجيال طويلة: أن الصحراء مغربية. لكن، وأنا أتابع تداعيات هذا الخبر من بعيد، من أقاصي الولايات المتحدة، أحسست بمفارقة عميقة: بم أفرح اليوم إن كانت الصحراء دائمًا مغربية؟ لقد كبرت في تطوان، مدينة لها تاريخها الخاص في فهم معنى “الملكية” و”الشرعية”، وربما في ذلك الجواب على السؤال.

تطوان مدينة عرفت في زمن مضى وطأة الحماية الإسبانية، وعرفت بعد رحيل المستعمر تلك المرحلة الغريبة التي اختلطت فيها الحدود بين ما هو مملوك حقًا وما هو مملوك عرفًا. كان بعض المغاربة، و ما زالوا، يسكنون بيوتًا تركها الإسبان، يملكون “المفتاح” لا أكثر، أي يملكون حق الدخول، وحق العيش، وحق الإحساس بالانتماء إلى المكان، ولكن ليس الحق القانوني في الأرض أو الجدران. وآخرون لديهم “ملكية عدلية” موثقة عند العدول، شهادة تثبت أن البيت لهم، ولكنها تبقى عرضة للشك ما لم يختم الملف بـ”التحفيظ” العقاري، ذلك الختم الذي يحول الوجود الواقعي إلى وجود قانوني لا نزاع فيه. في تطوان تعلمت أن بين “المفتاح” و “التحفيظ” مسافة واسعة، مسافة تقاس لا بالأمتار بل بدرجات الاعتراف. تبدو الصحراء المغربية اليوم، في عين التاريخ، مثل بيت تطواني قديم يسكنه أصحابه منذ أجيال. الراية المغربية ترفرف فوقه، والجيش يحرسه، والإدارة تسيره، والأهالي يعيشون فيه بطمأنينة ووطنية صادقة. كل مظاهر الحياة تشير إلى أنه بيت مغربي خالص، ومع ذلك ظل العالم لعقود يتردد في توثيق “الملكية”. كان المغرب يملك “المفتاح”، رمز السيادة الواقعية، واليوم بقرار الأمم المتحدة، نال شيئًا أشبه بـ”الملكية العدلية” — اعترافًا قانونيًا ضمنيًا بأنه صاحب الحق التاريخي، وإن لم يصل بعد إلى “التحفيظ الدولي” الكامل. إن هذا القرار الأممي لا يضيف إلى الوجدان المغربي يقينًا جديدًا، بل يضع ختمًا على يقين قديم وراسخ في الضمير الوطني. ومع ذلك، يبقى الشعور بالحذر قائمًا؛ فكما في نظام العقار غير المحفظ، قد يظل الحق عرضة للتأويل ما لم يوثق نهائيًا في سجل العالم. حين أتأمل الأمر، أجد أن الفرح اليوم ليس فرح اكتساب، بل فرح اعتراف. هو فرح أن يرى الآخر ما كنا نراه نحن منذ البداية. هو الانتقال من حقيقة نحياها إلى حقيقة يعترف بها الجميع. هو كما لو أن تطوانيًا سكن بيتًا عمره أربعون عامًا، فجاءه اليوم إشعار: “لقد تم تسجيل الملكية العدلية باسمك رسميًا.”

لن يتغير في يومه شيء: سيظل يسكن البيت ذاته، يفتح الباب بالمفتاح ذاته، يشرب قهوته في البهو ذاته. لكن قلبه سيشعر بخفة جديدة، كأن اليقين صار وثيقة. بين “المفتاح” و”الملكية العدلية” و”التحفيظ”، تمتد حكاية المغرب مع الصحراء، حكاية وطن يسكن أرضه قبل أن تسجل الأرض باسمه. وإذا كانت تطوان قد علمتنا أن الانتماء يسبق الوثيقة، فإن الصحراء تذكرنا أن السيادة تكتب أولًا بالوجود، ثم تختم بالحبر الأممي.

اقول قولي هذا و أختمه بشعر عمودي من طنجة الى الكويرة، على البحر الكامل كمال المغرب بصحرائه، و بروي مكسور ارتأيت ان اسكنه لا لضرورة شعرية بل بقرار أممي.

في تطوان نام المفتاح منكسر

يرنو لباب ما له مستقر

دار تقاسم سرها أسرارها

والملك فيها للشعور وللنظر

لا صك يثبت حقها إن سئلت

لكنه محفور قلب يذكر

يا تطوان يا رمز البدايات التي

سكنت ضمير الأرض قبل الدفتر

وهكذا الصحراء أختك لم تزل

تحيا ويحكمها الهوى والمخبر

ما غاب إلا ختم أمم لاح في

قرطاسه المحفوظ صحراؤكم در

قالوا سنقر الحق بعد تردد

قلنا ومن ينكر ضياء المنظر

فالملك فكر في التراب كأنه

سر يفتح في القلوب ولا يستطر

A note on implementing subgroup membership using the Tate pairing

Mon, 06 Oct 2025 00:00:00 +0000

The paper “Subgroup membership testing on elliptic curves via the Tate pairing” by Dmitrii Koshelev (https://eprint.iacr.org/2022/037.pdf) is a cute result. Let $E/F_p$ be an elliptic curve of order $N = c\cdot r$, with prime integer $r$. To check that a point $P \in E$ is of order $r$, the naive method is to check that $[r]P = \mathcal{O}$. The paper shows that, given the group structure $E \cong Z_{e_1} \bigoplus Z_{e_2 \cdot r}$ and $e_2 \mid p-1$ ($c$ being $e_1\cdot e_2$), it is sufficient to check that the Tate pairings:

$$ f_{e_1,P_1}(P)^{(p-1)/e_1} = 1 \quad \text{and}\quad f_{e_2,P_2}(P)^{(p-1)/e_2} = 1 $$

where $P_1$ and $P_2$ are points on $E$ of orders $e_1$ and $e_2$ respectively.

$E$ is not necessarily pairing-friendly. Pairing-friendliness just means that the embedding degree $k$ is small enough to have fast arithmetic and big enough to have good security (e.g. $k=12$ for BLS12 and BN curves). Here $k=1$ and we only care about performance. To compute these pairings, we need to compute:

the Miller functions $f_{e_i,P_i}$
the final exponentiations by $(p-1)/e_i$

The whole idea of the paper is that when $e_i$ are small, these two steps become very efficient to implement.

Step 2

Let us start with step 2. Given $f\in F_p$, checking that $f^{(p-1)/e_i} =_? 1$ is equivalent to checking if $f$ is an $e_i$-th residue in $F_p$, i.e. $\exists z \in F_p$ s.t. $z^{e_i} = f \pmod p$. This is known as Euler criterion. For small $e_i$, this can be performed more efficiently than exponentiation, by using Euclidean algorithms. The power residue symbol satisfy similar relations to the GCD and hence one can adapt GCD algorithms to compute power residue symbols. For $e_i = 2$, this is known as the Legendre symbol and can be computed efficiently using the binary GCD algorithm (see Pornin’s algorithm and gnark-crypto implementation by Arya). For bigger $e_i \leq 16$, there are similar algorithms — although less “CPU-friendly” than the binary-GCD. However, one can always resolve to exponentiations.

Step 1

Computing Miller functions is done through Miller loops. For small $e_i$, we can explicitly give the formulas. For example when $e_i=2$, the paper states that $f_{e_i,P_i} = X - X_{P_i}$ which is true when the curve is given in short Weierstrass form $E_{sw}: Y^2=X^3+AX+B$. When $e_i=1$, $f_i=1$ trivially. When $e_i=2^m$, the paper gives the formula in page 5.

Discussion

I believe that the result is significantly performant only when $e_1=e_2=2$, in which case we can compute the Legendre symbol efficiently using the binary-GCD algorithm. For other cases it is still moderately fast using exponentiations, or someone has to implement efficient Euclidean-type higher power residue symbols.

Now let us focus on the case $e_1=e_2=2$. This happens for the curve Bandersnatch used in Verkle trie. It is mostly efficient when given in twisted Edwards form $E_{ed}: ax^2+y^2=1+dx^2y^2$. So to implement this test with input points $(x,y)\in E_{ed}$, we need to map $(x,y)$ to $(X,Y) \in E_{sw}$. The formula is:

$$ X = (\frac{a-d}{4})\cdot(\frac{1+y}{1-y}) + \frac{a+d}{6} $$

and we don’t need the $Y$ coordinate.

To avoid inverses we use the fact that $(\frac{1/x}{p})2 = (\frac{x}{p})2$. Thus, $f{2,P_i} = X - X{P_i}$ becomes:

$$ 12(a-d)^2(1-y)[(5a - d - 12X_{P_i}) + (a - 5d + 12X_{P_i})y] $$

or equivalently

$$ t_2 (1-y)(t_1 + t_0y) $$

with $t_2=12(a-d)^2$, $t_1=5a - d - 12X_{P_i}$ and $t_0=a - 5d + 12X_{P_i}$ some pre-computed constants.

For Bandersnatch implementers, they just need to take this last formula with:

$X_{P_1} = \texttt{0x23e93c143a3aa62dfef158aabe40ed250530ac9369509c984891a87e04178ed3}$
$X_{P_2} = \texttt{0x5de00fbdcf0964d2188e44aec311d927af0f7e94e94fca97c891a87d84178ed1}$

which leads, for the first point, to:

$t_0=1$
$t_1=1$
$t_2=\texttt{0x384d1c153c878eea316b96e5c340cf6abd025b636bd74122926c66eb6fa86d15}$

and, for the second, to:

$t_0=\texttt{0x636b1e56f54c03e873dd6068f2f238776f43b4a3d72a357835d2fc15ba90cdea}$
$t_1=\texttt{0x108288fc3451795fbf5c779f16af9f8de479ef5f28d42686ca2d03e9456f321d}$
$t_2=\texttt{0x34f9acec8bf92f766108eca94020963ae3496e2743876768b74534c34ef9473e}$

A full implementation in gnark-crypto can be found here: https://github.com/Consensys/gnark-crypto/pull/708

Fast Elliptic Curve Scalar Multiplications in SN(T)ARK Circuits

Wed, 01 Oct 2025 00:00:00 +0000

Proof systems of arbitrary computations have found many applications in recent years. However, the proving algorithm has a consequent complexity tied to the size of the computation being proved. Thus, proving large computations is quite inefficient. One of these large computations is the scalar multiplication over an elliptic curve. In this work, we provide new techniques for reducing the time corresponding to proving a scalar multiplication, using integer lattice reduction or a (half) extended Euclidean algorithm in a ring of integers. We investigate optimizations in the case of small (complex multiplication) discriminant curves, and its generalization for multi scalar multiplications as used in signature verification. We provide an optimized Golang implementation for different elliptic curves in different proof systems settings. The speed-up in proving time is between 22% and 53% compared to the previous state-of-the-art.

On pairing implementation

Thu, 24 Jul 2025 00:00:00 +0000

This talk was about implementing bilinear pairings, with focus on gnark-crypto optimizations. It covers the mathematical foundations of pairings, their applications in cryptography, and practical considerations for efficient implementation. The talk also discusses challenges faced during the implementation process and how they were addressed, providing insights into the complexities of working with advanced cryptographic primitives.

Batch subgroup membership testing on pairing-friendly curves

Sat, 19 Jul 2025 00:00:00 +0000

Fast elliptic curve scalar multiplications in SN(T)ARK circuits

Fri, 23 May 2025 00:00:00 +0000

Zero-knowedge proofs and blockchains

Thu, 24 Apr 2025 00:00:00 +0000

In this presentation, we will explore the fascinating intersection of zero-knowledge proofs and blockchain technology. We will begin by demystifying zero-knowledge proofs, explaining their fundamental principles and tracing their evolution from theoretical primitives to practical tools in cryptography. Following this, we will delve into the world of blockchain, discussing its reliance on cryptographic techniques to ensure security and integrity. The core of the talk will focus on the necessity of zero-knowledge proofs in blockchain applications, addressing privacy and scalability concerns. We will highlight how blockchain technology has spurred significant advancements in zero-knowledge proof research, fostering collaboration between academia and industry. Finally, I will present my own contributions to the field, including the optimization of mathematical building blocks for zero-knowledge proofs and their concrete applications within blockchain systems. This presentation aims to provide a comprehensive understanding of the critical role zero-knowledge proofs play in enhancing blockchain technology and to share insights from cutting-edge research in this dynamic area.

Cipher Challenge 2025 — UM6P

Sat, 12 Apr 2025 00:00:00 +0000

I helped organize the Cipher Challenge 2025 — Cryptography Edtion held at the University Mohammed VI Polytechnique (UM6P) in Rabat, Morocco. The event took place on April 12 and 13, 2025, and was a great success, attracting participants from various universities and institutions in Morocco.

My contribution was twofold: Prior to the event, I created (most of) the challenges and also assisted in grading the students. On April the 12th, I gave a keynote talk on Modern “Applications of Cryptography”. The material I contributed can be found at: https://cipherchallenge.github.io/.

Modern Applications of Cryptography

Sat, 12 Apr 2025 00:00:00 +0000

I helped organize the Cipher Challenge at UM6P College of Computing, a competition that brings together students from all over Morocco. The material I contributed can be found at: https://cipherchallenge.github.io/. I gave a keynote presentation that delves into the fascinating world of cryptography and its evolution from classical techniques to modern applications. This talk provides a comprehensive overview of how cryptography has been traditionally used for encryption and digital signatures, and then explores groundbreaking advancements that are shaping the future of secure communication and data protection. Throughout the talk, we provide concrete examples of how these cryptographic techniques are being utilized in popular platforms and technologies, including Playstation, TikTok, Apple, WhatsApp, and various blockchains such as Bitcoin and Ethereum. By the end of the session, the goal is for the attendees to have a deeper appreciation for the critical role cryptography plays in our digital world and the innovative ways it continues to evolve to meet new challenges.

Elliptic curves and SNARKs — Past, present and future.

Tue, 12 Nov 2024 00:00:00 +0000

Elliptic curves are used in many proof systems. Some systems (e.g. Bulletproofs) use plain curves (e.g. ed25519). Some (e.g. Groth16, KZG-PLONK) use pairing-friendly curves (e.g. BLS12-381). Some recursive systems require pairing-friendly 2-cycle (e.g. MNT4/6) or 2-chains (e.g. BLS12-377/BW6-761). Some other recursive/folding systems require plain 2-cycle (e.g. Pasta). In this talk we will go through the difference between these curves and why there isn’t a silver bullet curve for all scenarios.

On proving scalar multiplications in SNARKs

Mon, 11 Nov 2024 00:00:00 +0000

We show a way to implement GLV-like scalar multiplication in SNARK circuits in the absence of an efficient endomorphism. When this latter is available, we show how to turn proving a scalar multiplication into proving a 4 dimensional multi-scalar multiplication of small scalars.

Fake GLV

Fri, 20 Sep 2024 00:00:00 +0000

 _____ _ ____ _ __ __
| ___|_ _| | _____ / ___| |\ \ / /
| |_ / _` | |/ / _ \ | | _| | \ \ / /
| _| (_| | < __/ | |_| | |__\ V /
|_| \__,_|_|\_\___| \____|_____\_/

You don’t need an efficient endomorphism to implement GLV-like scalar multiplication in SNARK circuits

Introduction

P-256, also known as secp256r1 and prime256v1, is a 256-bit prime field Weierstrass curve standardized by the NIST. It is widely adopted in internet systems, which explains its myriad use cases in platforms such as TLS, DNSSEC, Apple’s Secure Enclave, Passkeys, Android Keystore, and Yubikey. The key operation in elliptic curves based cryptography is the scalar multiplication. When the curve is equipped with an efficient endomorphism it is possible to speed up this operation through the well-known GLV algorithm. P-256 does unfortunately not have an efficient endomorphism (see parameters) to enjoy this speedup.

Verifying ECDSA signatures on Ethereum through precompiled contracts, i.e. smart contracts built into the Ethereum protocol (there are only 9) is only possible with the secp256k1 curve and not the P-256. Verifying ECDSA signatures on P-256 requires computing scalar multiplications in Solidity and is especially useful for smart-contract wallets, enabling hardware-based signing keys and safer, easier self-custody. Different solutions can bring P-256 signatures on-chain. There are primarily three interesting approaches: (zk)-SNARK based verifiers, smart contract verifiers (e.g. [Dubois23], Ledger/FCL (deprecated), smoo.th/SCL and daimo/p256verifier), and native protocol precompiles (EIP/RIP 7212).

Using SNARK (succinctness) properties, provides a great way to reduce gas cost for computation on Ethereum (e.g. ~232k gas for Groth16, ~285k gas for PLONK and ~185k gas for FFLONK). This is very competitive with (and sometimes better that) the currently gas-optimal smart contract verifier. Moreover one can batch many ECDSA verifications in a single proof, amortizing thus the gas cost. However verifying P-256 signatures in a SNARK circuit can be very expensive i.e. long proving time. This is because the field where the points on the P-256 curve lie is different than the field where the SNARK computation is usually expressed. To be able to verify the proof onchain through the procompile the SNARK field needs to be the BN254 scalar field. Different teams tried to implement the ECDSA verification on P-256 in a BN254 SNARK circuit efficiently. Among these: zkwebauthn/webauthn-halo2, https://github.com/zkwebauthn/webauthn-circom and PSE/circom-ecdsa-p256.

If P-256 had an efficient endomorphism we could have optimized the proving time a great deal!

In this note we show a way to implement a GLV-like scalar multiplications in-circuit without having an efficient endomorphism.

Other applications

This technique can be applied to any elliptic curve without an efficient endomorphism (e.g. Curve25519, P-384, MNT-753 (k=4, k=6), STARK curve, $\mathcal{B}$ of “cycle5”, …). See this database for other curves.
This would question the choice of Bandersnatch (an embedded endomorphism-equipped curve over BLS12-381) over Jubjub (an embedded curve over BLS12-381 without endomorphism) for Ethereum Verkle trees.
This can speedup ECDSA verification in Starknet and Cairo (through the STARK curve).
This can speedup natively the folding step (à la Nova) of Ed25519 signatures through the 2-cycles proposed here by Aurore Guillevic.

Background

Standard scalar multiplication

Let $E$ be an elliptic curve defined over the prime field $\mathbb{F}_p$ and let $r$ be a prime divisor of the curve order #$E(\mathbb{F}_p)$ (i.e. the number of points). Let $s \in \mathbb{F}_r$ and $P(x,y) \in E(\mathbb{F}_p)$, we are interested in proving scalar multiplication $s\cdot P$ over the $r$-torsion subgroup of $E$, denoted $E[r]$ (i.e. the subset of points of order $r$).

The simplest algorithm is the standard left-to-right double-and-add:

INPUT: s = (s_{t−1},..., s_1, s_0), P ∈ E(Fp).
OUTPUT: sP.
1. Q ← ∞.
2. For i from t−1 downto 0 do
2.1 Q ← 2Q.
2.2 If s_i = 1 then Q ← Q + P.
3. Return(Q).

If/else branching is not possible in SNARK circuits so this is replaced by constant window table lookups inside the circuit. This can be achieved using polynomials which vanish at the constants that aren’t being selected, i.e. a 1-bit table lookup Q ← s_i * Q + (1 - s_i) * (Q+P). Hence this double-and-add algorithm requires $t$ doublings, $t$ additions and $t$ 1-bit table lookup. This can be extended to windowed double-and-add, i.e. scanning more than a bit per iteration using larger window tables, but the multiplicative depth of the evaluation increases exponentially. We use affine coordinates for doubling/adding points because inverses cost as much as multiplications, i.e. instead of checking that $1/x$ is $y$ we provide $y$ out-circuit and check in-circuit that $x\cdot y = 1$. However since we start with $Q ← ∞$ it is infeasible to avoid conditional branching since affine formulas are incomplete. Instead, we scan the bits right-to-left and assume that the first bit s_0 is 1 (so that we start at Q ← P), we double the input point P instead of the accumulator Q in this algorithm and finally conditionally subtract (using the 1-bit lookup) P if s_0 was 0.

INPUT: s = (s_{t−1},..., s_1, s_0), P ∈ E(Fp).
OUTPUT: sP.
1. Q ← P.
2. For i from 1 to t−1 do
2.1 If s_i = 1 then Q ← Q + P.
2.2 P ← 2P.
3. if s_0 = 0 then Q ← Q - P
4. Return(Q).

GLV scalar multiplication

However it is well known that if the curve is equipped with an efficient endomorphism then there exists a faster algorithm known as [GLV]. :::info Example 1 : suppose that $E$ has Complex Multiplication (CM) with discrimant $-D=-3$, i.e. $E$ is of the form $y^2=x^3+b$, with $b \in \mathbb{F}_p$. This is the case of BN254, BLS12-381 and secp256k1 elliptic curves used in Ethereum. There is an efficient endomorphism $\phi: E \rightarrow E$ defined by $(x,y)\mapsto (\omega x,y)$ (and $\mathcal{O} \mapsto \mathcal{O}$) that acts on $P \in E[r]$ as $\phi(P)=\lambda \cdot P$. Both $\omega$ and $\lambda$ are cube roots of unity in $\mathbb{F}_p$ and $\mathbb{F}_r$ respectively, i.e. $\omega^2+\omega+1 \equiv 0 \pmod p$ and $\lambda^2+\lambda+1 \equiv 0 \pmod r$. ::: :::info Example 2 : suppose that $E$ has Complex Multiplication (CM) with discrimant $-D=-8$, meaning that the endomorphism ring is $\mathbf{Z}[\sqrt{−2}]$. This is the case of the Bandersnatch elliptic curves specified in Ethereum Verkle trie. There is an efficient endomorphism $\phi: E \rightarrow E$ whose kernel is generated by a 2-torsion point. The map can be found by looking at 2-isogeneous curves and applying Vélu’s formulas. For Bandersnatch it is defined by $(x,y)\mapsto (u^2\cdot \frac{x^2+wx+t}{x+w},u^3\cdot y\cdot \frac{x^2+2wx+v}{(x+w)^2})$ for some constants $u,v,w,t$ (and $\mathcal{O} \mapsto \mathcal{O}$) that acts on $P \in E[r]$ as $\phi(P)=\lambda \cdot P$ where $\lambda^2+2 \equiv 0 \pmod r$. ::: The GLV algorithm starts by decomposing $s$ as $s = s_0 + \lambda s_1$ and then replacing the scalar multiplication $s \cdot P$ by $s_0 \cdot P + s_1 \cdot \phi(P)$. Because $s_0$ and $s_1$ are guaranteed to be $\leq \sqrt{r}$ (see Sec.4 of [GLV] and Sec.4 of [FourQ] for an optimization trick), we can halve the size of the for loop in the double-and-add algorithm. We can then scan simultaenously the bits of $s_0$ and $s_1$ and apply the Strauss-Shamir trick. This results in a significant speed up but only when an endomorphism is available. For example the left-to-right double-and-add would become:

INPUT: s and P ∈ E(Fp).
OUTPUT: sP.
1. Find s1 and s2 s.t. s = s1 + 𝜆 * s2 mod r
1.1 let s1 = (s1_{t−1},..., s1_1, s1_0)
1.2 and s2 = = (s2_{t−1},..., s2_1, s2_0)
2. P1 ← P, P2 ← 𝜙(P) and Q ← ∞.
3. For i from t−1 downto 0 do
3.1 Q ← 2Q.
3.2 If s1_i = 0 and s2_i = 0 then Q ← Q.
3.3 If s1_i = 1 and s2_i = 0 then Q ← Q + P1.
3.4 If s1_i = 0 and s2_i = 1 then Q ← Q + P2.
3.5 If s1_i = 1 and s2_i = 1 then Q ← Q + P1 + P2.
4. Return(Q).

Using the efficient endomorphism in-circuit is also possible (see [Halo, Sec. 6.2 and Appendix C] or [gnark implementation] for short Weierstrass curves and [arkworks] and [gnark] implementations for twisted Edwards). But one should be careful about some extra checks of the decomposition $s = s_0 + \lambda s_1 \mod r$ (not the SNARK modulus). The integers $s_0, s_1$ can possibly be negative in which case they will be reduced in-circuit modulo the SNARK field and not $r$.

The fake GLV trick

Remember that we are proving that $s\cdot P = Q$ and not computing it. We can “hint” the result $Q$ and check in-circuit that $s\cdot P - Q = \mathcal{O}$. Now, if we can find $u,v \leq \sqrt{r}$ such that $v\cdot s = u \pmod r$ then we can check instead that $$ (v\cdot s)\cdot P - v\cdot Q = \mathcal{O}$$ which is equivalent to $$ u\cdot P - v\cdot Q = \mathcal{O}$$ The thing now is that $u$ and $v$ are “small” and we can, similarly to the GLV algorithm, halve the size of the double-and-add loop and apply the Strauss-Shamir trick.

Solution: running the half-GCD algorithm (i.e. running GCD half-way) is sufficient to find $u$ and $v$. We can apply the exact same trick for finding the lattice basis as in the GLV paper (Sec. 4). For completeness we recall the algorithm hereafter. We apply the extended Euclidean algorithm to find the greatest common divisor of $r$ and $s$ (This gcd is 1 since $r$ is prime.) The algorithm produces a sequence of equations $$w_i \cdot r + v_i \cdot s = u_i$$ for $i = 0, 1, 2, \dots$ where $w_0 = 1, v_0 = 0, u_0 = r, w_1 = 0, v_1 = 1, u_1 = s$, and $u_i \geq 0$ for all $i$. We stop at the index $m$ for which $u_m \geq \sqrt{r}$ and take $u = u_{m+1}$ and $v = -v_{m+1}$. Note: By construction $u$ is guaranteed to be a positive integer but $v$ can be negative, in which case it would be reduced in-circuit modulo the SNARK modulus and not $r$. To circumvent this we return in the hint $u$, $v$ and a $\texttt{b}=1$ if $v$ is negative and $\texttt{b}=0$ otherwise. In-circuit we negate $Q$ instead when $\texttt{b}=1$.

Implementation

A generic implementation in the gnark library is available at gnark.io (feat/fake-GLV branch). For Short Weierstrass (e.g. P256) look at the scalarMulFakeGLV method in the emulated package and for twisted Edwards (e.g. Bandersnatch/Jubjub) look at the scalarMulFakeGLV method in the native package.

Benchmark

The best algorithm to implement scalar multiplication in a non-native circuit (i.e. circuit field ≠ curve field) when an efficient endomorphism is not available is an adaptation of [Joye07] (implemented in gnark here). Next we compare this scalar multiplication with our fake GLV in a PLONKish vanilla (i.e. no custom gates) circuit (scs) over the BN254 curve (Ethereum compatible). We also give benchmarks in R1CS.

P-256	Old (Joye07)	New (fake GLV)
$[s]P$	738,031 scs / 186,466 r1cs	385,412 scs / 100,914 r1cs
ECDSA verification	1,135,876 scs / 293,814 r1cs	742,541 scs / 195,266 r1cs

Note here that the old ECDSA verification uses Strauss-Shamir trick for computing $[s]P+[t]Q$ while the new version is merely two fake GLV multiplications and an addition.

Comparison

p256wallet.org is an ERC-4337 smart contract wallet that leverages zk-SNARKs for WebAuthn and P-256 signature verification. It uses PSE/circom-ecdsa-p256 to generate the webAuthn proof, and underneath PSE/circom-ecdsa-p256 to generate the ECDSA proof on P-256 curve. The github README reports 1,972,905 R1CS. Compiling our circuit in R1CS results in 195,266 R1CS. This is more than a 10x reduction, which is not only due to the fake GLV algorithm but also to optimized non-native field arithmetic in gnark.

Other curves

Similar results are noticed for other curves in short Weirstrass, e.g. P-384 and STARK curve:

P-384	Old (Joye07)	New (fake GLV)
$[s]P$	1,438,071 scs	782,674 scs
ECDSA verification	2,174,027 scs	1,419,929 scs

STARK curve	Old (Joye07)	New (fake GLV)
$[s]P$	727,033 scs	380,210 scs
ECDSA verification	1,137,459 scs	732,131 scs

and also in twisted Edwards e.g. Jubjub vs. Bandersnatch:

Jubjub	Old (2-bit double-and-add)	New (fake GLV)
$[s]P$	5,863 scs / 3,314 r1cs	4,549 scs / 2,401 r1cs

Bandersnatch	Old (GLV)	New (fake GLV)
$[s]P$	4,781 scs / 2,455 r1cs	4,712 scs / 2,420 r1cs

EDIT: Thanks to Ben Smith for reporting that a similar idea was proposed in [SAC05:ABGL+] for ECDSA verification. We note that, in our context, the trick applies to a single scalar multiplication and that the half GCD is free through the hint.

zkAggregation in Linea

Sun, 02 Jun 2024 00:00:00 +0000

This presentation is about the proof aggregation protocol in the Linea zkEVM. It uses the elliptic 2-chain of curves BLS12-377 and BW6-761 to aggregate PLONK-KZG proofs and reduce the verification cost.

Discovering New Elliptic Curves (podcast)

Wed, 15 May 2024 00:00:00 +0000

Your browser does not support the audio element. Download the episode.

In this podcast episode, Antonio Sanso (EF researcher) and myself discuss with Anna Rose (host) and Nico (co-host from Geometry research) our new work, Families of prime-order endomorphism-equipped embedded curves on pairing-friendly curves and dive into Elliptic Curve cryptography, Bandersnatch and Verkle Tries amongst much more, before dissecting what terms in the title of this paper truly mean. After getting into the weeds of cryptographic technicalities, the group explores where this work could be used and what it would enable.

gnark and 2-chain aggregation for Linea

Fri, 29 Mar 2024 00:00:00 +0000

This presentation is about the gnark and gnark-crypto libraries and how they are used to aggregate proofs on the Linea zkEVM.

Families of prime-order endomorphism-equipped embedded curves on pairing-friendly curves

Tue, 10 Oct 2023 00:00:00 +0000

Faster Montgomery multiplication and Multi-Scalar-Multiplication for SNARKs

Mon, 11 Sep 2023 00:00:00 +0000

This presentation is about the conference article that can be found online here. The bottleneck in the proving algorithm of most of elliptic-curve-based SNARK proof systems is the Multi-Scalar-Multiplication (MSM) algorithm. In this paper we give an overview of a variant of the Pippenger MSM algorithm together with a set of optimizations tailored for curves that admit a twisted Edwards form. We prove that this is the case for SNARK-friendly chains and cycles of elliptic curves, which are useful for recursive constructions. Our contribution is twofold: first, we optimize the arithmetic of finite fields by improving on the well-known Coarsely Integrated Operand Scanning (CIOS) modular multiplication. This is a contribution of independent interest that applies to many different contexts. Second, we propose a new coordinate system for twisted Edwards curves tailored for the Pippenger MSM algorithm.Accelerating the MSM over these curves is critical for deployment of recursive proof systems applications such as proof-carrying-data, blockchain rollups and blockchain light clients. We implement our work in Go and benchmark it on two different CPU architectures (x86 and arm64). We show that our implementation achieves a 40-47% speedup over the state-of-the-art implementation (which was implemented in Rust). This MSM implementation won the first place in the ZPrize competition in the open division “Accelerating MSM on Mobile” and will be deployed in two real-world applications: Linea zkEVM by Consensys and probably Celo network.

Pairings in Rank-1 Constraint System

Wed, 12 Jul 2023 00:00:00 +0000

This presentation is about the conference article that can be found online here. In this work, we consider efficiently implementing pairings in Rank-1 Constraint Systems (R1CS), a widely used model to express SNARK statements. We show that our techniques almost halve the arithmetic circuit depth of the previously best known pairing implementation on a Barreto–Lynn–Scott (BLS) curve of embedding degree 12, resulting in 70% faster proving time. We also investigate and implement the case of BLS curves of embedding degree 24.

Pairings in Rank-1 Constraint System

Tue, 20 Jun 2023 00:00:00 +0000

ZPrize competition 2022

Tue, 04 Apr 2023 00:00:00 +0000

Zero-knowledge cryptography is a groundbreaking new technology enabling privacy, interoperability, and scalability for Web 3.0 protocols and applications. Like the DARPA Grand Challenge, select teams will compete for monetary prizes spanning a range of categories. Over $7M in prize money has been committed, along with token grants from sponsoring projects.

All winning submissions will become open-source libraries for the benefit of all. We hope this foundation can support the next generation of decentralized protocols and applications to enable secure, interoperable, and scalable applications for the next-generation web.

With Gautam Botrel from Consensys, we participated in the inaugural edition of ZPrize (2022) in the open division: “ACCELERATING MSM ON MOBILE” as the gnark team. Our submission resulted in a 4.2x speedup over the baseline and won the first place. The prize was $259,147.

ACCELERATING MSM ON MOBILE

Proving on mobile devices is a transformative technology for applications including private transactions, self-sovereign identity, and scalable computation. Multi-scalar multiplication (MSM) is a core operation for producing zkSNARKs, and it is the primary bottleneck and barrier for deployment of proving on mobile. This prize will focus on minimizing latency of computing MSM in native mobile applications.

The goal was to write the fastest MSM over BLS12-377 curve on a mobile device (Samsung Galaxy A13 5G). The specification details can be found here.

Our submission was written in Go, and derived from the gnark-crypto project. On the target device, for a random BLS12-377 G1 MSM ($n = 2^{16}$), we measured:

~2309ms for the reference benchmark
~509ms for our submission

This is a -77.9% optimisation.

Code and techniques

The code can be found on github here under Apache-2 or MIT license.

We experimented several approaches; here is a description of the key findings for the final ones:

It uses our in-house gnark-crypto/bls12377 package, which out of the box performs very well compared to the zprize baseline. The MSM algorithm is described in this paper (to appear in TCHES, Issue 3) and the Go code is documented. We introduced a bls12-377 algorithmic optimization; the “bucket/pippenger” method now uses an optimized twisted edwards extended cordinate system, resulting in a significant performance improvement (~30% on some target).
We perform a static build targetting a 64bit arm linux architecture, which allows without a complicated build procress to run 64bit code on the target device. We copy the output in the armv7 (32bit) destination folder; in a production deployment, Java calling code must at runtime check for the actual CPU architecture and switch to a fallback if it’s 32bit (outside of the scope of the challenge). Note that while the submission spawn a process at each msm call, other ways may turn out more efficient (allocate the verifying key on the stack, communicate with the process with unix sockets, …).
We hand tuned the field arithmetic for the Multiplication targetting the arm64 architecture. Our pure-go version performed better than the arm assembly one, and resulted in a ~20% speed up on some platforms compared to existing version in gnark-crypto.
We implemented and optimized a dedicated Squaring algorithm (rather than calling the Multiplication as in gnark-crypto) following our previous work https://hackmd.io/@gnark/modular_multiplication (also described in the TCHES paper), which resulted in significant perf improvement on the target device. This is not used in the twisted edwards extended MSM, only in the parameterized Jacobian version which uses Affine points as input (branch: buckets/jacobian, performance: ~600ms for $2^16$).
For the target (arm64) we add ~40lines of arm assembly for a small function (fp.Butterfly(a, b) -> a = a + b; b = a - b). The perf impact is ~5%, as it speeds up a bit the UnifiedMixedAdd point addition in the buckets (msm). The rest of the submission is compiled from pure Go code;
On this device, our GPU experimentations were not promising.
We raised an issue to the Golang team. Once the fix is merged into the latest Golang compiler release, we might squeeze an extra 5-10% perf improvement.

Results

The results were annouced on 04-04-2023 in this blog post.

The main sponsor (Ocelot) authored a more detailed announcement for the specific Mobile division in this post.

The arithmetic of pairing-based proof systems

Fri, 18 Nov 2022 00:00:00 +0000

The arithmetic of pairing-based proof systems

Fri, 18 Nov 2022 00:00:00 +0000

This is my PhD defense.

Faster Montgomery multiplication and Multi-Scalar-Multiplication for SNARKs

Sun, 23 Oct 2022 00:00:00 +0000

Optimizing cryptographic algorithms in gnark

Thu, 13 Oct 2022 00:00:00 +0000

This talk is about algorithmic optimizations techniques used in gnark. In particular, we show that the implementation of Multi-Scalar-Multiplication (MSM) is 45% faster compared to competitors libraries. We also explain optimizations in the pairing computations both out-circuit and in-circuit. To the best of our knowledge, these implementations are best-in-class.

Elliptic curves and zk-SNARKs

Fri, 16 Sep 2022 00:00:00 +0000

A proof system is a protocol where one party (called the prover) tries to convince another party (called the verifier) that a given statement is true. In the class of non-interactive proof systems, a particularly interesting concept for proving the computational integrity is the Succinct Non-interactive ARgument of Knowledge (SNARK). It provides a computationally sound proof, cheap to verify and small compared to the size of the statement or the witness. Bilinear pairings over elliptic curves have become key ingredients for instantiating such SNARKs. In this thesis we investigate tailored pairing-friendly elliptic curves to efficiently implement SNARKs. We present a study at three stages of the process: curves to instantiate a SNARK, curves to instantiate a recursive SNARK, and also curves to express an elliptic-curve related statement. We provide new constructions of curves for SNARKs and new families of 2-chain curves for recursive SNARKs. We derive and implement in open-source efficient algorithms to speed up the arithmetic on these curves: Co-factor clearing, subgroup membership testing, multi-scalar multiplication and pairings over 2-chains. We also study and optimize elliptic curves arithmetic and pairings as a SNARK statement, yielding to the fastest recursive proof generation in pairing-based settings.

Cofactor clearing and subgroup membership testing on pairing-friendly elliptic curves

Wed, 20 Jul 2022 00:00:00 +0000

An important cryptographic operation on elliptic curves is hashing to a point on the curve. When the curve is not of prime order, the point is multiplied by the cofactor so that the result has a prime order. This is important to avoid small subgroup attacks for example. A second important operation, in the composite-order case, is testing whether a point belongs to the subgroup of prime order. A pairing is a bilinear map e: G1×G2 → GT where G1 and G2 are distinct subgroups of prime order r of an elliptic curve, and GT is a multiplicative subgroup of the same prime order r of a finite field extension. Pairing-friendly curves are rarely of prime order. In this talk, we investigate cofactor clearing and subgroup membership testing on these composite-order curves. First, we generalize a result on faster cofactor clearing for BLS curves to other pairingfriendly families of a polynomial form from the taxonomy of Freeman, Scott and Teske. Second, we investigate subgroup membership testing for G1 and G2. We fix a proof argument for the G2 case that appeared in a preprint by Scott in late 2021 and has recently been implemented in different cryptographic libraries. We then generalize the result to both G1 and G2 and apply it to different pairing-friendly families of curves. This gives a simple and shared framework to prove membership tests for both cryptographic subgroups.

Pairings in Rank-1 Constraint System

Wed, 08 Jun 2022 00:00:00 +0000

Families of SNARK-friendly 2-chains of elliptic curves

Wed, 01 Jun 2022 00:00:00 +0000

In this talk, we first are interested in families of 2-chains in which the BW6-761 curve would fall. We present a family of BW6 curves from any BLS12 curve and derive generic formulas, in terms of the BLS12 curve seed u, and integer parameters ht,hy. We extend this work to a 2-chain family of BW6 curves from BLS24 curves. To achieve higher levels of security in the target finite field of the outer curves, we compare a larger field characteristic thanks to larger parameters ht,hy, to the larger embedding degrees 8 and 12 obtained with Cocks-Pinch curves. Finally, we argue that the BLS12 and BLS24 based families are respectively tailored for Groth’16 and KZG-based SNARKs recursive proof composition, and we present a short list of curves with an optimized implementation along with benchmarks.

A survey of elliptic curves for proof systems

Thu, 12 May 2022 00:00:00 +0000

Elliptic curves and SNARKs

Wed, 11 May 2022 00:00:00 +0000

Elliptic curves have become key ingredients for instantiating zero-knowledge proofs and more generally proof systems. Recently, there have been many tailored constructions of these curves that aim at efficiently implementing different kinds of proof systems. In this talk we provide a comprehensive view on existing work. We present an overview at two stages of the process; curves to instantiate a SNARK and curves to instantiate a recursive SNARK.

Co-factor clearing and subgroup membership testing on pairing-friendly curves

Fri, 29 Apr 2022 00:00:00 +0000

Pairings in R1CS

Thu, 21 Apr 2022 00:00:00 +0000

This presentation is about how to efficiently express a pairing a Rank-1 Constraint System (R1CS) arithmetic circuit. The goal is to reduce the time complexity to SNARK prove a bilinear pairing. A corresponding research paper will be soon available on ePrint.

Families of SNARK-friendly 2-chains of elliptic curves

Fri, 15 Apr 2022 00:00:00 +0000

Families of SNARK-friendly 2-chains of elliptic curves

Tue, 01 Mar 2022 00:00:00 +0000

On choosing suitable elliptic curves for zk-SNARK

Tue, 09 Feb 2021 00:00:00 +0000

This presentation is about requirements and methods to contruct tailored and optimized elliptic curves for zkSNARK applications.

zk-SNARK 101

Fri, 05 Feb 2021 00:00:00 +0000

This presentation is an introduction to the concept of zkSNARKs alongside an step-by-step toy example of Pinocchio-ish zkSNARK protocol.

Optimized and secure pairing-friendly elliptic curve suitable for one layer proof composition

Tue, 15 Dec 2020 00:00:00 +0000

This presentation is about a joint paper with Aurore Guillevic that can be found online here. It proposes new families of elliptic curves that are tailored and optimized for recursive SNARKs.

Faster proof composition with the BW6-761 curve

Wed, 08 Jul 2020 00:00:00 +0000

This presentation is about using the BW6-761 curve to generate and verify faster composed Groth'16 zk-SNARK proofs and its application in EY Blockchain effort to privacy-preserving blockchains.

Optimized and secure pairing-friendly elliptic curve suitable for one layer proof composition

Tue, 31 Mar 2020 00:00:00 +0000

This presentation is about a joint paper with Aurore Guillevic that can be found online here. It introduced a new elliptic curve, namely BW6-761 that is very efficient for one-layer recursive SNARKs compared to the state-of-the-art.

Optimized and secure pairing-friendly elliptic curves suitable for one layer proof composition

Tue, 24 Mar 2020 00:00:00 +0000

Nightfall - The Open Source Privacy Solution for Ethereum

Thu, 10 Oct 2019 00:00:00 +0000

We believe that public blockchain is the future of business to business transactions. However, two issues - privacy and scalability - will need to be solved if this vision is to be fully realised. This talk will explain the motivations behind the open-source nightfall code and how it is intended to tackle the first of these issues. We cover the operation of the protocol, the method by which it provides complete privacy, and how developers can use it to build their own applications by making use of its smart contract infrastructure and the ZoKrates framework. We will also present our modelling of transaction costs, which shows that nightfall can already provide a cost-competitive alternative to private blockchains for many situations and how that will be true for a growing number of use cases in the near future.

ZK-PAR 0x01

Thu, 15 Aug 2019 00:00:00 +0000

Once upon a time, the entire Universe was inside a bubble that was thousands of times smaller than a pinhead. It was hotter and denser than anything we can imagine. Then it suddenly exploded. The Universe that we know was born. Time, space and matter all began with the Big Bang. In a fraction of a second, the Universe grew from smaller than a single atom to bigger than a galaxy. And it kept on growing at a fantastic rate. It is still expanding today.

A biodiversity of species came to life. The total number of all species living on Earth estimates there are about 8.7 million species but the most important specie of all is one that, in the geological time scale, appeared recently. It is the human specie. So much happened on Earth before we came to call it home, but if we only focus on human life there is too much to narrate about.

One of the main discoveries by humans was fire control, it was an important step in their culture. It allowed humans to cook food and get warmth and protection. But before that, making fire also allowed destructive use as humans used it to attack predators, insects and each others.

Everyone knows this story but today I’m going to tell a similar story, as fascinating as this one. It is the story of elliptic curves. I’ll walk you through the pre- big bang and the post- big bang, I’ll show you the biodiversity of elliptic curves species and will present you to the specie used in cryptography, a.k.a. the Homo genus. Finally, we will go through a similar story to fire control that is pairing control.

I presented this story the 4th of July in Paris during ZK-PAR 0x01, the first Zero Knowledge meetup in the french capital. The meetups started in Tel-Aviv and then London and now Paris. They are intended for anyone interested in applied cryptography for privacy-preserving technology. The presentations are usually focussed on technical and practical aspects of this technology, notably its relation to blockchain technology. You can find more information and community discussions in the Facebook group and the Youtube channel.

ZK-PAR 0x01 hosted two speakers, Bastien Teinturier and myself. Bastien talked about anonymous payments in Bitcoin’s Lightning network and I invite you to watch his video and go through his slides. After that, my presentation was about this story of elliptic curves, or the story of life. Here is the video and the slides.

Thanks to the sponsors of ZK-PAR: Beam, Consensys and Bitcoin.fr

Elliptic curves in cryptography

Thu, 04 Jul 2019 00:00:00 +0000

I this presentation the 4th of July in Paris during ZK-PAR 0x01, the first Zero Knowledge meetup in the french capital. The meetups started in Tel-Aviv and then London and now Paris. They are intended for anyone interested in applied cryptography for privacy-preserving technology. The presentations are usually focussed on technical and practical aspects of this technology, notably its relation to blockchain technology. You can find more information and community discussions in the Facebook group and the Youtube channel.

ZK-PAR 0x01 hosted two speakers, Bastien Teinturier and myself. Bastien talked about anonymous payments in Bitcoin’s Lightning network and I invite you to watch his video and go through his slides.

ZEXE - Zero-knowledge EXEcution

Thu, 09 May 2019 00:00:00 +0000

ZK Study club is a learning group where people from the zero-knowledge/Blockchain community gather to study a specific topic. There have been so far nine sessions that discussed several cryptographic topics. The first four sessions broke down the ZK-STARKs, the fifth session was a deep dive into RSA accumulators, the sixth was about Sigma protocols, the seventh discussed the Fiat-Shamir heuristic and the eighth was about multi-party computations. The sessions are usually recorded and put available online:

The ninth session happened last Monday 6th May and was the first of a series about the recent paper called “Zexe: Enabling Decentralized Private Computation” by Sean Bowe from ZCash, Alessandro Chiesa, Pratyush Mishra and Howard Wu from UC Berkeley, Matthew Green from Johns Hopkins University and Ian Miers from Cornell Tech. I had the chance to lead this session and discuss the paper’s ideas with wonderful community enthusiasts. The video can be found here and the session’s notes here.

Basically, the aim behind Zexe is to write private smart contract on a distributed ledger. Such a scheme can be constructed by doing offline computation and uploading a proof of correct execution to the ledger. The proof should be zero-knowledge, succinct and easy to verify. To do this, the paper introduces a new cryptographic primitive called decentralized private computation (DPC) and comes up with some efficient implementation tricks that range from zkSNARK optimization, recursive proof composition and a new set of elliptic curves.

The starting point of Zexe is to extend Zerocash protocol to more general token-based blockchains. This protocol provides a privacy-preserving version of Bitcoin-like blockchains via the use of zero-knowledge proofs (ZKP). To create a coin a user publishes a commitment and to consume it he publishes its unique serial number alongside some ZKP that the serial numbers belong to some old coins and that the commitments preserve the same total value. In Zexe, an integer value coin is a data payload record and the ZKP assures that an arbitrary function was applied to old records to create the new ones. The problem now is, if we want the function to be user-defined, how can we make sure it stays private, and if so, how can we isolate “malicious” functions from “honest” functions? One straightforward solution would be to add a ZKP that proves the same function was used; this basically boils down to using a Zerocash per function (i.e. per token) which results in a functionality limitation as one cannot do private cross-token swaps for instance and moreover the anonymity set would be limited to each each specific token history. Another solution would be to use a universal function on the ledger and embed user-defined functions within the data payload. To do this, we need a minimalist shared execution environment (some sort of an operating system) where different processes can be executed without violating the privacy of each. Zexe calls it records nano-kernel where a record is now: data payload, birth predicate for records creation, death predicate for records consumption, transaction memorandum for public input needed by the predicates and auxiliary input for private input. The problem now is, if the predicates are arbitrary functions, do we need a SNARK per predicate or a universal SNARK? While awesome research is being conducted to propose a universal SNARK like Sonic, efficient implementations are yet to come. A solution to the cost of universality would be to do “a proof of a proof”, that is, generating a proof of the predicate and then generating another proof of the previous proof that will be verified on the ledger. This way, we need a single circuit on the ledger and a circuit per predicate offline.

While empirically proved via cycles of elliptic curves, recursive proofs are not efficient at 128-bit security level. In fact, a SNARK proof (i.e. in Groth16) is a set of points on an elliptic curve that has a subgroup of order $n$ so the generation has arithmetic in $\mathbb{F}_n$ whereas the verification uses p airing computations where most of the computations are on an extension of the field size $p$. This causes an arithmetic mismatch that results in an overhead of $log(p)$ when one wants to implement naïvely a verification circuit. The solution to this is to use a cycle of elliptic curves where the field size of one is equal to the subgroup order of the other and vice-versa. The only pairing-friendly cycle of elliptic curves we know is the set of MNT4 and MNT6 curves that have a low embedding degree and thus are not quite efficient at 128-bit security level. In Zexe scheme, we need merely a proof of a proof so the authors came up with a chain of elliptic curves rather than a cycle, namely a Cocks-pinch curve embedded over a BLS curves that is highly 2-adic with respect to both the field size and the subgroup order.

This is somewhat an overview of Zexe, but the paper includes more contributions such as delegating the generation of a proof to an untrusted worker (delegated DPC), minimizing operations over the (heavy) embedded cocks-pinch curve, optimizing the NP statements à la Zcash and more…

Shamir Secret Sharing — The magic 3S Spell

Tue, 02 Apr 2019 00:00:00 +0000

“There are no more Horcruxes. It’s just you and me. Neither can live while the other survives, and one of us is about to leave for good…” —Harry Potter and the Deathly Hallows, Chapter 36: The Flaw in the Plan.

The Horcrux hunt was a mission started by Albus Dumbeldore and given to Harry Potter to find all of Lord Voldemort’s remaining Horcruxes and destroy them. Obsessed with immortality from a young age, Lord Voldemort created a series of Horcruxes in an effort to prevent his death. A Horcrux is a vessel into which one places a piece of one’s soul to protect one from mortal death. Voldemort split his soul into 7 secret parts in a way that reconstruction is possible. It is widely believed that the process for Horcrux splitting involves a spell and a horrific act is performed after a murder has been committed, but this is not true. Voldemort invented this cover story to keep secret the very simple spell he used (a wizard patent for the technical term) — it is called the 3S spell.

The 3S spell is nothing but a Shamir secret sharing scheme. In this scheme, a dealer (Voldemort) splits a secret (his soul) into multiple shares (Horcruxes) in a way that reconstruction is only possible when combining all of the shares or some sufficient fixed number of them. The spell uses some basic polynomial algebra magic (1st year at Hogwarts) and some finite field wizardry.

Basic scheme

Let’s $s$ be the secret and $n$ the number of shares, a dealer can construct a secret sharing scheme where only $t < n$ custodians can reconstruct the secret $s$. He first generates a $t$-degree polynomial $P(X) = p_0 + p_1X + p_2X^2 + · · · + p_t X^t$ where $p_0$ is the secret $s$ and $p_1, p_2, \dots , p_t$ are chosen at random from the finite field we’re working in (e.g. $\mathbb{F}_31$ which means integers from 0 to 30). He then computes the points $v_1 = P(1), v_2 = P(2), \dots and v_n = P(n)$ and distributes these $n$ shares to the custodians. Any $t < n$ shares can reconstruct the polynomial $P$ with interpolation (e.g. Lagrange interpolation) and recover the original secret $s = P(0)$. Note that any $t − 1$ shares would interpolate with high probability a false polynomial.

One can draw an infinite number of polynomials of degree 2 through 2 points. 3 points are required to define a unique polynomial of degree 2. This image is for illustration purposes only — Shamir’s scheme uses polynomials over a finite field, not re-presentable on a 2-dimensional plane (Wikipedia)

This is a polynomial curve over a finite field — now the order of the polynomial has seemingly little to do with the shape of the graph (Wikipedia)

Verifiable scheme

There are two problems with the basic scheme:

A malicious custodian can submit a false share
A malicious dealer can distribute false shares

The first issue can be addressed by adding some fingerprint to the secret. This way, if a malicious custodian submit a false share, the reconstructed secret won’t be correct and the fingerprint lost. One way to do this is by concatenating the secret s with the hash of the last 31 bytes of s, i.e. s ← (s||sha256(s[: −32]). However, identifying the malicious custodian remains impossible in this approach.

The solution to the second problem, can both identify a malicious dealer and a malicious custodian in the first scenario. A simple approach would be to publicly publish the hashes of shares but this might be impractical in some use-cases where the number of custodians increases quickly. In fact, each custodian will have a database of auxiliary information that may increases quickly over the time. A better approach was proposed by Feldman and uses homomorphic commitments.

Feldman’s approach:

In this approach, the dealer publishes the commitments of polynomial’s coefficients $p_0= s$ and $p_1, p_2, \dots, p_t$ that are homomorphic with respect to multiplication. Such a commitment is known to be a Pedersen’s commitment. Given a finite field of prime characteristic $p$ and a generator $g$, the dealer publishes $c_0 \equiv g^s \pmod p, c_1 \equiv g^{p_1} \pmod p, \dots$ and $c_t \equiv g^{p_t} \pmod p$. Given the commitments $c_i$ for $i \in [0, t]$, the is no way to retrieve the secret $s$ and the coefficients $p_1, p_2, \dots, p_t$ because of the hardness of the discrete logarithm problem. A custodian can verify that the share $v_i$ he was given by the dealer wasn’t tampered with thanks to the homomorphic property of Pedersen’s commitments. In fact,

This is basically the magic 3S spell that allowed Lord Voldemort to split his soul into 7 horcruxes. The process is rather simple that even Ronald Weasley can perform, but Tom Riddle invented the horrific-act-after-murder story to keep away wizardry newbies from reaching immortality.

Yes, I ruined your childhood memories. Sorry Not Sorry.

Zero-knowledge summit - ZK0x03

Sat, 23 Mar 2019 00:00:00 +0000

On March 22nd 2019, I attended the third edition of zero-knowledge summit ZK0x03 held at Berlin. The summit was organized by Anna Rose and Fredrik Harrysson from zero-knowledge podcast, which is made for fellow developers and people looking to educate themselves on the inner workings of the blockchain zero-knowledge tech space. This one-day event focused on zero-knowledge topics, zkSNARK, MPCs, STARKs and blockchain scaling solutions featuring the following speakers:

Ahivu Levy (StarkWare Industries) discussing scalability with STARKs
Harry Roberts (Ethsnarks) sharing the history of high-level programming languages for making zk proofs
John ‘Tux’ Pacific (Nucypher) on fully homomorphic encryption
Jordi Baylina (Iden3) on Circom and Snarkjs
Izaak Meckler (CODA Protocol) on the secrets of SNARK programming
Alex Vlasov (Matter Labs) on scaling & privacy with zkSNARKs in Ethereum
Aurélien Nicolas (QED-it, zkproofs.org) discussing zk standards
Zachary Williamson (Aztec Protocol) on ERC-1724 confidential digital assets
Igor Barinov (POA Network) on scaling with xDai and side chains
Jonathan Levi (HACERA) on ZKPs for both permissioned and permissionless blockchains

There were also discussions on confidential transaction scheme based on 1-out-of-N proofs, GDPR and privacy of Zcash shielded transactions as well as deep-dive workshops on practical use and implementation of ZKPs, building a STARK with pen and paper and more. The program ran from 9:30 a.m. to 8 p.m. where talks were presented at two different filmed stages while roundtables and circle discussion happened on two other dedicated rooms. The full program can be found here and the playlist of videos here.

Since the program was running in parallel, I couldn’t make it to all the presentations so I chose 3 talks and 2 roundtables I was most interested in:

Talk 1: scalability first with STARK — Ahivu levy (StarkWare industries)

video of the talk

This talk was about scalability using STARKs — It was presented by Ahivu, the head product of StarkWare, a startup that leverages on STARK technology to improve blockchain scalability and privacy. The main takeaway is that they are planning to release their first product mid-april which is a decentralized exchange (DEX) engine on Ethereum. While STARKs can solve privacy on the blockchain as it is widely believed, Ahivu thinks that they are the best candidate to solve scalability thanks to the exponentially small verifier running time.

Talk 2: fully homomorphic encryption the road to secure computation — John Tux Pacific (NuCypher)

video of the talk

This talk was about secure multiparty computation (SMPC), trusted execution evironments (TEE) and fully homomorphic encryption (FHE) with focus on the latter. It was presented by John who is a cryptography engineer at NuCypher, a startup that works mainly on proxy-reencryption and FHE to build privacy infrastructure for the blockchain. John started by presenting SMPC, TEE and FHE, and and then listed the pros and cons of each approach. Because FHE seems to be the ideal approach, he then exposed how research is aiming to address FHE cons.

Talk 3: Scaling and privacy with zkSNARKs in Ethereum — Alex Vlasov (Matter Labs)

video of the talk

Although the title of this talk is “scaling and privacy with zkSNARKs in Etherem”, the presentation was mainly about the new zero-knowledge protocol called SONIC and its comparison to the actual Groth16 zkSNARK protocol implemented in ZCash. The talk was presented by Alex who works at Matter Labs, a startup aiming to scale the blockchain using zero-knowledge proofs. SONIC is a new ZK proving system that requires an updatable and universal trusted setup — that means unlike other SNARKs, SONIC does not require a trusted setup for each circuit, but only a single setup for all circuits (up to a given circuit depth) and it never has to end, so it can be continuously secured by accumulating more contributions. To this point, Alex gave a nice comparison between usual SNARKs and SONIC; imagine you are playing a card game and you want some trusted deck of cards, in SNARKs you shuffle the deck and then you pass it to other players who shuffle it again every time you start a new game, but in SONICs you only shuffle the deck once and then “clone” it every time you start a new game (this works for every game that requires the same number of cards or less ~circuit depth). For efficiency comparison, Groth16 is still better (0.6s vs 9s for a single proof and 3s vs 11.5s for a batch of 5 proofs — according to Alex benchmark) but we still need an efficient SONIC implementation as in Bellman to compare apples to apples. The main takeaway is that SONICs are a real breakthrough that solve somewhat the SNARKs trusted setup issue. It is to mention that I discussed SONICs with Ariel Gabizon (former ZCash cryptographer who discovered the trusted setup counterfeiting bug in ZCash) after the talk and he believes that a lot of research is being conducted in this direction and more efficient protocols are likely to be proposed later this year.

Roundtable 1: GPU implementation of zksnark prover — Konstantin Panarin (Matter Lab)

This roundtable was animated by Konstantin from Matter Labs. He started by describing NVIDIA GPU architecture and code parallelization principles with examples, then he discussed how we can benefit from GPUs to speedup the proving step in Groth16 zkSNARKs. The most important part of the proving step (~60% of the computation time) is the multi-exponentiation and one way to do this efficiently is using Pippenger algorithm (ZCash by the way moved from Bos-Coster algortihm to Pippenger after Sapling activation). We discussed how the algorithm works and how it can be enhanced using NVIDIA GPUs keeping in mind that an enhancement should not only address the computation time but also the memory cost.

Roundtable 2: Building a STARK with pen and paper — Mathew Stevens and Micro Richter

This one was funny actually— we were 30 people at the beginning but only 10 stayed until the very end because of the heavy maths content. We deep dived into all the dirty details of the mathematical machinery behind zkSTARKS given a toy example (a Fibonacci sequence). The steps are:

Arithmetic intermediate representation (AIR) to show a computation as an execution trace with algebraic registers and to create polynomial contraints,
algebraic placement and routing (APR) to transform the AIR into functions that are Reed-Solomon codes if and only if the execution trace is a witness,
Reed-Solomon proximity testing (RPT) to check that an APR witness is an actual Reed-Solomon code in an efficient way, and
fast Reed-Solomon Interactive oracle proof of proximity (FRI) to efficiently check the proximity to the Reed-Solomon codes.

The summit was closed by a park bench panel animated by Anna and Fredrik in a game form. Anyone from the audience can ask any question but if it turns out to be an opinion/remark then she/he is invited on stage to answer the upcoming questions. Here is a question I asked (which is actually an opinion according to Mrs Justice Anna): “Zero-knowledge proofs (ZKP) like zkSNARKs or zkSTARKs are not proofs but arguments because the soundness is only computational and not statistical, so is it a mistake to call them proofs?”

Besides the talks which were really interesting, this event was an opportunity to meet a lot of people from the broad ZKP/Blockchain community and to discuss technical details with sometimes the authors of some papers I’ve been scouring over the few last months. For this reason, I want to thank the organizers Anna and Fredrik for putting all of this together and especially Xavier De Boissieu and Quentin Drouot from EY for making my attendance possible.

Encryption using elliptic curves

Thu, 03 Jan 2019 00:00:00 +0000

In my first post, we’ve seen that elliptic curves cryptography (ECC) was first introduced as a better alternative to public-key cryptography based on multiplicative groups of finite fields. In fact, ECC requires smaller keys compared to its finite field analog to provide equivalent security. Finite fields cryptosystems rely on the “hardness” of the discrete logarithm problem (DLP) to build cryptographic tools such as encryption (ElGamal), key exchange (Diffie-Hellman DH) and digital signature algorithms(DSA). Analogously, one expects to have ElGamal, DH and DSA counterparts thanks to the “hardness” of the equivalent elliptic curves discrete logarithm problem (ECDLP). However, it seems that only ECDH and ECDSA are popular. So, is there an ElGamal version for elliptic curves? Is direct encryption even possible with elliptic curves?

The use of elliptic curves in cryptography was suggested independently by Neal Koblitz and Victor S. Miller in 1985. The main reason was that previous asymmetric approaches were subject to subexponential-time index calculus algorithms that solve the underlying hard problems, whereas no subexponential-time algorithms are known for the discrete logarithm problem in a (suitably chosen) elliptic curve. Moreover, for the most part the best available algorithms are ones that have nothing to do with the specific structure of the elliptic curve group, but rather would work with essentially the same running time on any group. Such algorithms are said to be “generic”. In his paper, Koblitz suggested an encryption algorithm similar to ElGamal but it needed an invertible function to map plaintexts to points on an elliptic curve which made the scheme a bit impractical. The algorithm works as follows:

We set up an elliptic curve $E$ over a finite field $\mathbb{F}_p$ and a point $P$ of order $N$.
We need a public known invertible function $f$ that maps messages $m$ to points $P_m$ on $E$.
We choose a random secret key $x \in [1,N-1]$ and publish the point $Y=xP$ as public key.
Encryption: We choose a random integer $k \in [1,N-1]$, then calculate $C_1=kP$, $C_2=kY$ and $P_m=f(m)$. The ciphertext is the tuple $(C_1, C_2+P_m)$.
Decryption: From the ciphertext $(C, D)$ we calculate $C’=xC$ and retrieve the point $P_m$ with $P_m=D-C’$ ($=k(xP)+P_m-x(kP)$). Finally, we recover the message $m$ with $f^{-1}(P_m)$.

Basically, this is how we can do encryption on the elliptic curve but for real-world encryption this is somehow impractical because of the required invertible point mapping. One way to do it is interpreting the message as the $X$ coordinate of a curve point and computing a matching $Y$ coordinate. This has two drawbacks:

First, only about half of the $X$ values can be the first coordinate of a curve point and
second, one needs to compute a modular quadratic residue ($Y^2=X^3+aX+b$) to find the $Y$. This is not trivial and requires using Tonelli-Shanks algorithm.

So, for things to work, some variability (some bits which can be adjusted until a possible $X$ is reached) would be needed and since the size of the message would be severely limited (no bigger than $p$) this is hardly worthwhile.

For these reasons, direct encryption using elliptic curve is not practical but one can use hybrid encryption instead. That is, using ECDH to produce a shared secret value that will be used as a secret for some symmetric encryption algorithm (e.g. AES). This is called Elliptic Curve Integrated Encryption Scheme (ECIES).

Apple primes

Tue, 06 Nov 2018 00:00:00 +0000

What does this title mean?

Well, last week (October 30th, 2018), Apple published a security update for iOS 12.1 and macOS Mojave 10.14.1 that addresses an issue existing in the method for determining prime numbers. This method was implemented in Apple’s crytptographic library CoreCrypto which is used in many different cryptographic applications. Martin Albrecht, Jake Massimo and Kenny Paterson of Royal Holloway and Juraj Somorovsky of Ruhr University were issued the CVE-2018–4398 for discovering the pitfall. The full academic paper can be found here. According to the paper, an attacker may be able to exploit a weakness in the primality test to incorrectly identify prime numbers.

So what are prime numbers and why they are used in cryptography? How to efficiently test the primality of a number? and what would be the impact if composite numbers are incorrectly declared primes (Apple primes)?

Prime numbers

A prime number is a positive integer that has exactly two positive integer factors, 1 and itself. For example, if we list the factors of 28, we have 1, 2, 4, 7, 14, and 28. That’s six factors. If we list the factors of 29, we only have 1 and 29. That’s two factors. So we say that 29 is a prime number, but 28 isn’t. Primes are central in number theory because of the fundamental theorem of arithmetic: every natural number greater than 1 is either a prime itself or can be factorized as a product of primes that is unique up to their order.

There are infinitely many primes (Euclid gave a simple proof by contradiction or you can check more recent proofs using Euler product for the Riemann zeta function or the irrationality of $\pi$ and Leibniz formula) but no known simple formula separates them from composite numbers.

A deterministic straightforward method to check if an integer $p$ is prime is to test whether $p$ is a multiple of any integer between $2$ and $\sqrt{p}$, but this method or any deterministic approach remains very slow when dealing with big numbers.

Primality tests

Many popular primality tests are probabilistic tests because they provide provable bounds on the probability being fooled by a composite number. These tests use, apart from the tested number, some other numbers (witnesses) which are chosen at random; the usual randomized primality tests never report a prime number as composite, but it is possible for a composite number to be reported as prime. The probability of error can be reduced by repeating the test with several independently chosen values of witnesses . The basic structure of randomized primality tests is as follows:

Randomly pick a number .
Check some equality (corresponding to the chosen test) involving and the given number . If the equality fails to hold true, then is a composite number and the test stops.
Repeat from step 1 until the required accuracy is achieved. After one or more iterations, if is not found to be a composite number, then it can be declared probably prime.

Fermat Primality Test

Fermat’s Little Theorem

If $p$ is as prime number and $a$ is a positive integer less than $p$, then the remainder of $a^{p-1}$ devising by $p$ is $1$ i.e. $a^{p-1} \equiv 1 \pmod p$

Test Algorithm

If $p$ is the number which we want to test for primality, then we could randomly choose $a$, such that $a < p$ and then calculate $a^{p-1} \equiv \pmod p$. If the result is not $1$, then by Fermat’s Little Theorem $p$ cannot be prime. What if that is not the case? We can choose another $a$ and then do the same test again. We could stop after some number of iterations and if the result is always $1$ in each of them, then we can state that is probably prime. The more iterations we do, the higher is the probability that our result is correct.

Miller-Rabin Primality Test

Key Ideas
1. Fermat’s Little Theorem.
2. If $p$ is prime and $x^2 \equiv 1 \pmod p$, then $x \equiv 1$ or $-1 \pmod p$

The number we want to test its primality is necessarily odd, then $p-1$ is even and we can write $p-1 = 2^s d$ where $d$ is an odd number and $d ≥ 0$.

If $p$ is prime, then either $a^d \equiv 1 \pmod p$ as in this case, repeated squaring from $a^d$ will always yield $1$, so $a^{p-1} \pmod p$ will be $1$; or $a^{2^r d} \equiv -1 \pmod p$ for some $r$ such that $0 \leq r \leq s$, as repeated squaring from it will always yield $1$ and finally $a^{p-1} \equiv 1 \pmod p$. If none of these hold true, $a^{p-1}$ will not be $1$ for any prime number (otherwise there will be a contradiction with fact #2).

Test Algorithm

Let be $p$ the given number which we have to test. First we rewrite $p-1$ as $2^s d$. Now we pick some in range and then check whether or for . If both of them fail, then is definitely composite. Otherwise is probably prime. We can choose another and repeat the same test to reduce the probability of error.

Apple’s pitfall

In number theory, a Carmichael number is a composite number $n$ which satisfies the modular arithmetic congruence relation $a^{p-1} \equiv 1 \pmod p$ for all integers $a$ which are coprime to $n$, i.e. a composite number that satisfies Fermat’s test. Robert Carmichael found the first and smallest such number, 561, which explains the name “Carmichael number”. Indeed, $561=3 \times 11 \times 17$ and $a^{560} \equiv 1 \pmod{561}$ for all $a$ coprime to $561$.

Like the Fermat, the Rabin-Miller test has Carmichael numbers (choices of $a$ for which the test declares a composite integer to be a probable prime) but there are fewer. It turns out for any composite $n$, including Carmichael numbers, the probability $n$ passes the Miller-Rabin test is at most 1/4 (on average it is significantly less.) Thus the probability $n$ passes several runs decreases exponentially. However, the bases $a$ should be chosen randomly so an attacker wouldn’t be able to find Carmichael numbers with respect to these bases.

In corecrypto library, Apple performs $t < 256$ rounds of Miller-Rabin testing, selecting the bases incrementally from a hard-coded list of the first 256 primes. When performing, for instance, $t = 32$ rounds of testing, the probability of a false prime classification is estimated as 1/$2^{64}$. However, since the bases $a$ generation is deterministic, an attacker should be able to find composite numbers that fool the test. This was done in the paper using the method described in Arnault, F “Constructing Carmichael numbers which are strong pseudoprimes to several bases” paper. An example of such a composite 1024-bit number of the form $n=p \times q \times r$ is given below:

n = 105216055594390884840438324972769319399722594046651360392070071794973423530188471087867855419188813164954561140227145977855514336985746250989366318940490798583710597151720075427387437940535767395296272532149397065590267303873620351321073058502920032770522836726669005262088263964215455869031740912313201227043

with

p = 123282949929736752510916282638002560328626287433241467864741378859343760091491850110380631340085554443
q = 28724927333628663335043493854654596556569924971945262012484741274227096101317601075718687102239934184987
r = 29711190933066557355130824115758617039198935271411193755402672305101846182049535876601732152960618620523

Secure Two-Party Computation (S2PC)

Mon, 22 Oct 2018 00:00:00 +0000

Not to toot my own horn here but when I was in high school I used to be quite popular :). I was moreover one of the least shy people I know but when it came to girls, I was interested in, I suddenly turn to this timid shell of a person. This awkward version of a popular guy is not uncommon and the fear of rejection is the reason that rattles us to the core. I still remember this girl from my high school I’ve never talked to, because of that fear — let’s call her Salma in the sequel (Any resemblance to actual persons, living or dead, is purely coincidental). No matter how much courage I’ve summoned and how firmly I’ve convinced myself I don’t care about the outcome, hearing no from Salma would have hurt. A graceful no hurts a great deal less but a cruel no in public drives a knife through the male psyche.

Growing up, I became a cryptographer and figured out a mathematical way to deal with such a situation. How can you make secure advances to Salma ? Is there a way to securely guess the outcome ? or simply put, how can you avoid a dismissive no in public ? The solution uses Yao’s Garbled circuits for secure two-party computation (S2PC).

Given private inputs $x$ and $y$ and a public function $f$, this method enables two parties to securely compute the outcome $f(x,y)$ without revealing the secrets $x$ and $y$. A circuit is just a way to represent a computation consisting of just operations on bits, like AND, OR, NOT and a garbled circuit is a way to “encrypt a computation” that reveals only the output of the computation, but reveals nothing about the inputs or any intermediate values. Our situation makes the basic way to understand how the protocol works. Let the secret $x$ be 1 if I am interested in Salma and 0 otherwise. Similarly, her secret $y$ is either 1 or 0. We want to securely compute a function that outputs 1 if we both are interested in each other and 0 otherwise — no one should be able to guess the inputs. A simple function would be an AND gate.

There are 4 possibilities in the truth table but only one is the actual reality. Next, we “garble” this circuit as follows: For each wire $x, y$ and z, we specify two random values corresponding to 0 and 1 and then we encrypt (using some symmetric cipher such as AES) the truth table by encrypting the output-wire key with the corresponding pair of input-wire keys. Which results in the Garbled Computation Table (GCT).

Given two input keys only one row of the GCT can be decrypted correctly. Next, we rearrange the GCT — so that no information is leaked — and send it to Salma along with my input key. Note that, since the key is random, there is no way to associate it with the actual bit. At this point, she has the GCT and my input key but needs the key I have already associated to her input bit. But just like me, Salma doesn’t want to reveal her secret (bit)! Neither want I to send her both keys, as she would be able to decrypt more than a GCT row. What we need here is a protocol in which a sender transfers one of potentially many pieces of information to a receiver, but remains oblivious as to what piece has been transferred. Fortunately, such a protocol exists and is called 1-out-of-2 oblivious transfer (OT). In the next section, I will present a simple 1–2 OT protocol but if you don’t know how RSA encryption works just skip this section since explaining it goes beyond the scope of this post.

1–2 Oblivious Transfer

Alice holds $m_0, m_1$, and an RSA key pair $(e, d, N)$. Bob holds the public key $(e, N)$ of Alice, $x \in {0,1}$ and wants $m_x$
Alice generates random $x_0, x_1$ and sends them to Bob
Bob chooses a random $k$, computes $v=y_x+k^e$ and sends $v$ to Alice.
Alice computes $k_0=(v-x_0)^d$ and $k_1=(v-x_1)^d$, and sends $m_0’=m_0+k_0$ and $m_1’=m_1+k_1$ to Bob
Bob computes $m_x=m_x’-k$ and learns nothing about $m’ _{1-x}$

Now, using 1–2 OT protocol, Salma can have her input key without me knowing anything about her secret bit. At this point, we can decrypt the GCT row corresponding to our secrets and reveal securely the output value. If it is a 0, none is able to tell who rejected the other and if it is a 1… Jackpot!

By and large, this is how we can do secure two-party computation. So, dear Salma, if by any chance you’re reading my post, here is my secret key ;)

0x3361736861206c6d616c69696969696b

Why elliptic curves are called "elliptic" ?

Sun, 14 Oct 2018 00:00:00 +0000

Every name tells a story. If you ask new parents “how did you choose your baby’s name?” sometimes the response will be a vague “Oh she chose!” but most of the time there is a story behind, and it’s often a great story about going through dozens of possibilities until one clicked. It goes from her favorite fictional character to her favorite great-aunt, so the baby has to be called Khaleesi. Obviously. In mathematics, it is no different. When mathematicians introduce their new baby to the world, they choose an appropriate name far from being random. In my last post, I have talked about elliptic curves and why they are used in cryptography. This triggered the question on why they are called “elliptic” even though they do not resemble ellipses in any way.

Elliptic curves are of cubic equations $y^2=x^3+ax+b$ while ellipses are of quadratic equations $x^2/a^2+y^2/b^2=1$. So, prima facie, there is no connection between them. But looking deeply into the history of elliptic curves, one finds out the connection. In the 18th century it was natural to ask about the arc length of an ellipse. In fact, despite their similarity to circles, ellipses are quite different. For example, a circle’s circumference is given by $2 \pi r$ and its area by $\pi r^2$ where $r$ is the radius. It is remarkable how the constant $\pi$ relates the circumference to the area given the radius $r$. But things are not that easy when dealing with ellipses. Given $a$ and $b$ as the semi-radii, the area of an ellipse is $\pi ab$ but the circumference is a more difficult question. More generally, the arc length of ellipses is difficult to calculate and is given either by a hard integral or by a rather formidable series. This question led to the study of $\sqrt{f(x)}$ where $f(x)$ is a polynomial of degree 3 or 4. These functions cannot be described with familiar calculus functions and came to be known as elliptic integrals. For circles, $f(x)$ is a quadratic polynomial and we get “circular integrals” which are easy to handle. for example, we know that $\int dx / (\sqrt{1-x^2}) = \sin ^{-1} (x)$ and the inverse of the function, namely $\sin{x}$, is well studied and easy to deal with. Thus, circular integrals lead to the periodic trigonometric functions. Similarly, studying the inverse of elliptic integrals leads to some doubly periodic functions which came to be known as elliptic functions (let’s call them ℘(z) in the sequel, because ℘ looks nice). Furthermore, all the derivatives are doubly periodic with the same periods and satisfy a cubic differential equation. Now in calculus, you learn about parametric equations and how they can describe a curve. By a parameterization of a curve $C$, we mean a continuous bijection from a set of numbers to the set of all points on $C$. For example, letting $x=a \sin{t}$ and $y=b \cos{t}$ with $t \in [0, 2 \pi)$ gives a familiar parameterization of the standard ellipse $x^2/a^2+y^2/b^2=1$. In the same way, we see that setting $x=℘(z)$ and $y=℘’(z)$ gives a parameterization of the cubic curve known today as an elliptic curve. Names are reservoirs of stories and this was the story behind elliptic curves’ name.

One last thing before I forget, dear future son, if this post lives long enough so that you are reading it now, I am sure you will understand why I called you Jon Snow. But for now, you know nothing Jon Snow.

Why do we use elliptic curves for cryptography?

Sun, 07 Oct 2018 00:00:00 +0000

In the series of posts I am willing to write, I will try to answer technical questions I have been asking myself throughout my readings about Maths, cryptography and Blockchain. For many questions, I couldn’t find easily or completely the answer I was looking for. One of these questions I faced is: Why did we even consider using elliptic curves for cryptography ? The question is “Why” rather than “How”. Elliptic curves are mathematical objects from the algebraic geometry and one should be normally surprised when discovering that such objects are used to encrypt data. In fact, elliptic curves are non-singular algebraic curves satisfying an equation of the form $y^3=x^3+ax+b$ (cf. figure 1).

Figure 1: Examples of elliptic curves over $\mathbb{R}^2$

Well, that doesn’t help us a lot.. And since I started this post with a question you have the right to ask more questions: What do these mathy words mean? How did we get this equation? And why are they even called “elliptic” even though they do not resemble “ellipses” in any way ? Don’t worry I’ve asked myself these same questions and we’re going to deep dive into the answers in later posts. For now, let’s go back to the main question: Why do we use these curves to encrypt data? To answer this we have to trace the evolution of cryptography over the years. The earliest known cryptographic schemes use a symmetric approach — that is using the same key for both encryption and decryption. A simple example of this approach and one of the oldest would be “Caesar cipher” in which each letter in the plaintext is replaced by a letter some fixed number of positions down the alphabet. In this scheme the encryption/decryption key is the fixed number of positions that must be kept secret and known only to the communicating parties. This symmetric approach is still widely used today through many ciphers such as AES, Blowfish or RC4 but the requirement of a secret symmetric key is still the main drawback. Cryptographers have been then looking for innovative asymmetric approaches where the decryption key differs from the encryption one. That is said, they have been looking for algorithms where it is easy to derive the decryption key (public) given the encryption key (private) and difficult the other way around — or mathematically put, a function that is straightforward to compute and computationally hard to inverse. One of the first algorithms proposed and still widely used nowadays is the famous RSA which relies on the hardness of the “factorization problem”. In fact, given two prime integers, it is easy to compute their multiplication but presumably hard to find the prime integers given the multiplication output. At this point you may (should) be asking why is it hard to factorize an integer and the answer is that there is no published algorithm that can do this in polynomial time (an algorithm is said to be of polynomial time if its running time is upper bounded by a polynomial expression in the size of the input for the algorithm). In fact, the best published asymptotic running time (on a classical computer, not a quantum one. Wait, quantum?) is for the general number field sieve (GNFS) algorithm which has a sub-exponential complexity. In short, integer factorization is “hard” in the sense of computational efficiency because we haven’t found just yet a reason for it to be easy, and we can’t prove it is hard. All this to come to the point that integer factorization, in my opinion, has nothing to do with the unknown primes distribution as widely believed. It is true that the problem is built upon the fundamental theorem of arithmetic which states that every integer can be uniquely represented as the product of prime numbers but I think that the chaotic nature of primes distribution has no bearing on the problem. There’s no reason to expect that factorization would become even a bit easier by proving the Goldbach conjecture, the twin primes conjecture or the Riemann Hypothesis for examples. However, the problem becomes computationally easier (polynomial time) when using quantum computers to run Shor’s algorithm as we will see on a later post. Another proposed asymmetric construction relies on the hardness of the “discrete logarithm” problem in cyclic groups. Given integers a and b in a carefully chosen group G, no efficient method is known for recovering the integer k such that $a=b^k$. In fact, the problem is quickly computable in a few special cases but in some cases there is not only no efficient algorithm known for the worst case, but the average-case complexity can be shown to be about as hard as the worst case using random self-reducibility. So choosing the group G is critical and a popular choice that provides good security assumptions is large prime order subgroups of groups $\mathbb{Z}_p$. These groups were used to build several known cryptographic protocols such as ElGamal encrytpion, Diffie-Hellman (DH) key exchange and Digital Signature Algorithm (DSA). However, using these groups requires large key sizes because of the sub-exponential GNFS algorithm as well. In fact, while computing discrete logarithms and factoring integers are distinct problems, both are special cases of the hidden subgroup problem for finite Abelian groups and thus, for both, the most efficient approach remains GNFS on a classical computer and Shor’s algorithm on a quantum computer. At this point, you may be thinking that somehow changing that group G from finite fields to elliptic curves may provide better security assumptions. You’re right! The best published algorithms to find discrete logarithms over elliptic curves are Pollard’s $\rho$ or baby-step-giant-step with a way better running time than GNFS. But wait, what is a discrete logarithm over elliptic curves? (you ask a lot of questions, huh?) Well, no worries, we will soon deep dive into all the machinery ;)

On the Performance and Security of Multiplication in $GF(2^N)$

Tue, 18 Sep 2018 00:00:00 +0000

Random Numbers Generation: Tests and Attacks

Thu, 13 Sep 2018 00:00:00 +0000