From f8f7bc9c3450f3934803a9d08a9b5a05a444f6d8 Mon Sep 17 00:00:00 2001 From: Brian Lawrence Date: Sat, 4 May 2024 16:47:55 -0500 Subject: [PATCH] KZG, IPA edits --- src/ec.typ | 6 +++--- src/ipa.typ | 8 +++++--- src/kzg.typ | 51 +++++++++++++++++++++++++++++++++++++++++++++------ 3 files changed, 53 insertions(+), 12 deletions(-) diff --git a/src/ec.typ b/src/ec.typ index 16bfb36..f35b58a 100644 --- a/src/ec.typ +++ b/src/ec.typ @@ -342,7 +342,7 @@ So now suppose Alice wants to set up a signature scheme. 2. Alice publishes $[d] in E$ as her *public key*. ] -Now suppose Alice wants to prove her identity to Bob, +Now suppose Alice wants to prove to Bob that she approves the message $msg$, given her published public key $[d]$. #algorithm[EdDSA signature generation][ @@ -389,12 +389,12 @@ $ a_1 g_1 + ... + a_n g_n = b_1 g_1 + ... + b_n g_n. $ Indeed, even if one fixes any choice of $2n-1$ of the $2n$ coefficients above, one cannot find the last coefficient. -#definition[ +#definition[ In these notes, if there's a globally known elliptic curve $E$ and points $g_1, ..., g_n$ have order $q$ and no known nontrivial linear dependencies between them, we'll say they're a *computational basis over $FF_q$*. -] +] #remark[ This may horrify pure mathematicians because we're pretending the map diff --git a/src/ipa.typ b/src/ipa.typ index 2add1a5..18ccd3c 100644 --- a/src/ipa.typ +++ b/src/ipa.typ @@ -12,7 +12,7 @@ So the roadmap is as follows: Throughout this section, $E$ is defined as in @notation, and there are fixed globally known generators -$g_1, ..., g_n, h_1, ..., h_n, u in E$ which are a computational basis. +$g_1, ..., g_n, h_1, ..., h_n, u in E$ which are a computational basis (@comp_basis). == Pitch: IPA allows verifying $c = sum a_i b_i$ without revealing $a_i$, $b_i$, $c$ @@ -45,7 +45,9 @@ The way IPA is done is by induction: one reduces verifying a vector for $n$ is good (hence $2n+1$ length) by verifying a vector for $n/2$ is good (of length $n+1$). -#todo[Link Aard's notes.0xparc.org post that motivates the whole thing] +To see how you might think of the idea on your own, +check out this +#link("https://notes.0xparc.org/notes/pedersen-ipa", "0xPARC blog post"). To illustrate the induction, we'll first show how to get from $n=2$ to $n=1$. So the given input to the protocol is @@ -207,7 +209,7 @@ polynomial commitments. === Application: revealing an element of a Pedersen commitment -Suppose Peggy have a vector $arrow(a) = angle.l a_1, ..., a_n angle.r$ +Suppose Peggy has a vector $arrow(a) = angle.l a_1, ..., a_n angle.r$ and a Pedersen commitment $v = sum a_i g_i$ to it. Suppose Peggy wishes to reveal $a_1$. The right way to think of this is as the dot product $arrow(a) dot arrow(b)$, diff --git a/src/kzg.typ b/src/kzg.typ index 4c3c37f..8ab2401 100644 --- a/src/kzg.typ +++ b/src/kzg.typ @@ -35,7 +35,8 @@ We retain the notation $[n] := n dot g in E$ defined in @armor. === Bilinear pairing The map $[bullet] : FF_q -> E$ is linear, -but as written we can't do "armored multiplication": +meaning that $[a + b] = [a] + [b]$, and $[n a] = n[a]$. +But as written we can't do "armored multiplication": #claim[ As far as we know, given $[a]$ and $[b]$, one cannot compute $[a b]$. @@ -58,9 +59,9 @@ but for some reason everyone justs says *pairing* instead. A curve is called *pairing-friendly* if this pairing can be computed reasonably (e.g. BN254 is pairing-friendly, but Curve25519 is not). -This construction is actually uses some really deep graduate-level number theory +This construction actually uses some really deep graduate-level number theory (in contrast, all the math in @ec is within an undergraduate curriculum) -that are well beyond the scope of these lecture notes. +that is well beyond the scope of these lecture notes. Fortunately, we won't need the details of how it works; but we'll comment briefly in @pairing-friendly on what curves it can be done on. And this pairing algorithm needs to be worked out just once for the curve $E$; @@ -99,6 +100,23 @@ Meanwhile, the secret scalar $s$ is never revealed to anyone. This only needs to be done by a trusted party once for the curve $E$. Then anyone in the world can use the resulting sequence for KZG commitments. +#remark[ + The trusted party has to delete $s$ after the calculation. + If anybody knows the value of $s$, the protocol will be insecure. + The trusted party will only publish $[s^0] = [1], [s^1], ..., [s^M]$. + Given these published values, it is (probably) extremely hard to recover $s$ -- + this is a case of the discrete logarithm problem. + + You can make the protocol somewhat more secure by involving several different trusted parties. + The first party chooses a random $s_1$, computes $[s_1^0], ..., [s_1^M]$, and then discards s_1. + The second party chooses $s_2$ and computes + $[(s_1 s_2)^0], ..., [(s_1 s_2)^M]$. + And so forth. + In the end, the value $s$ will be the product of the secrets $s_i$ + chosen by the $i$ parties... so the only way they can break secrecy + is if all the "trusted parties" collaborate. +] + == The KZG commitment scheme Peggy has a polynomial $P(X) in FF_p [X]$. @@ -180,6 +198,27 @@ If we chose $E$ to be BN254, the following property holds: This integer $k$ is called the *embedding degree*. This section is an aside explaining how the embedding degree affects pairing. -#todo[write this section, describing - the #link("https://en.wikipedia.org/wiki/Weil_pairing", "Weil pairing"). -] +The pairing function $pair(a, b)$ takes as input two points $a, b in E$ +on the elliptic curve, +and spits out a value $pair(a, b) in FF_{p^k}^*$ -- +in other words, a nonzero element of the finite field of order $p^k$ +(where $k$ is the embedding degree we just defined). +In fact, this element will always be a $q$th root of unity in $FF_{p^k}$, +and it will satisfy $pair([m], [n]) = zeta^{m n}$, +where $\zeta$ is some fixed $q$th root of unity. +The construction of the pairing is based on the +#link("https://en.wikipedia.org/wiki/Weil_pairing", "Weil pairing"). +in algebraic geometry. +How to compute these pairings is well beyond the scope of these notes; +the raw definition is quite abstract, +and a lot of work has gone into computing the pairings efficiently. +(For more details, see these +#link("https://crypto.stanford.edu/pbc/notes/ep/pairing.html", "notes").) + +The difficulty of computing these pairings is determined by the size of $k$: +the values $pair(a, b)$ will be elements of a field of size $p^k$, +so they will require 256 bits even to store. +For a curve to be "pairing-friendly" -- in order to be able to +do pairing-based cryptography on it -- we need the value of $k$ to be pretty small. + +