Merge branch 'main' of https://github.com/nglaeser/crypto-glossary

docs/Areas-of-Cryptography/blockchain.md

@@ -21,6 +21,21 @@
 - **Validity**: If all honest parties input $b$, all honest parties will output $b$
 - **Termination**: All honest parties eventually terminate and output some value
 
+### State Representation
+
+There are two main *accounting models* used to represent the state of a blockchain system:
+
+**UTXO**
+: Unspent Transaction Output. Every transaction *tx* consists of input transactions and output transactions; before executing *tx*, the chain (miners) check that the input transactions are *unspent*, i.e., they are as-yet unused output transactions from some previous *tx'* (they are in the UTXO set). Once *tx* is processed its inputs are removed from the UTXO set. That means that there is a directed acyclic graph (DAG) describing how assets (UTXOs) have moved between addresses. This DAG represents the global state. (Account balances are computed locally by adding up an account's UTXOs.)  
+Used by: Bitcoin, Litecoin, and Monero.
+
+**Account-based**
+: The account model simply maintains a database mapping accounts to balances. This database represents the global state.
+Use by: Ethereum.
+
+!!! tip "Further Reading"
+    [The UTXO vs. Account Model](https://www.horizen.io/academy/utxo-vs-account-model/)
+
 ## Layer 2
 
 !!! summary

docs/Areas-of-Cryptography/ecc.md

@@ -5,6 +5,11 @@
 
 **Elliptic curve**
 : 
+    - Pairing-friendly: Baretto-Naehrig (BN) curves (e.g., BN254), Barreto-Lynn-Scott (BLS) curves (e.g., BLS12-381), Kachisa-Schaefer-Scott (KSS) curves, Miyaji-Nakabayashi-Takano (MNT) curves. Pairing-friendly curves [have all three of the common pairings](https://crypto.stackexchange.com/questions/70802/do-weil-tate-and-ate-pairings-exist-on-all-elliptic-curves) (Weil, Ate, and Tate).
+    - No pairing: secp256k1, NIST P-256, Curve25519
+    <!-- https://www.ietf.org/proceedings/105/slides/slides-105-cfrg-pairing-friendly-curves-00.pdf -->
+
+## Pairing-Based Cryptography
 
 **Pairing** { #pairing }
 : In its most common form in cryptography, a pairing is a map $e: G_1 \times G_2 \rightarrow G_T$, where $G_1, G_2$ are additive cyclic groups of prime order $q$ and $G_T$ is a *multiplicative* cyclic group of order $q$. The map $e$ is required to have the following properties:
@@ -26,4 +31,6 @@
     - **Type-2**: $G_1 \neq G_2$ but there exists an efficiently computable homomorphism $\phi: G_2 \rightarrow G_1$. [DDH](../assumptions.md#diffiehellman-dh-assumptions) is easy in $G_2$ but thought to be hard in $G_1$, referred to as the [external Diffie-Hellman (XDH) assumption](../assumptions.md#diffiehellman-dh-assumptions).  
     { #type-2 }
     - **Type-3**: $G_1 \neq G_2$ and there is no efficiently computable homomorphism between $G_1$ and $G_2$. [DDH](../assumptions.md#diffiehellman-dh-assumptions) is thought to be hard in both $G_1$ and $G_2$, referred to as the [symmetric external Diffie-Hellman (SXDH) assumption](../assumptions.md#diffiehellman-dh-assumptions).  
-    { #type-3 }
+    { #type-3 }
+
+    Examples: [Weil pairing](https://crypto.stanford.edu/pbc/notes/ep/pairing.html), [Tate pairing](https://crypto.stanford.edu/pbc/notes/ep/tate.html), [Ate pairing](https://eprint.iacr.org/2006/110)

docs/Areas-of-Cryptography/zk.md

@@ -54,6 +54,8 @@ The "special" part means that this property implies soundness.
 1. the proof size is "small"
 1. verification is "fast"
 
+    There is some disagreement on exactly how to define "small" and "fast" in the above: constant, polynomial in the security parameter, polylogarithmic in the statement size, sublinear in the witness? <!-- Can link to Justin's post on misconceptions (#2) once it's out https://a16zcrypto.com/posts/article/17-misconceptions-about-snarks/ -->
+
     What exactly is meant by "small" and "fast" often depends on the author.  
     "Small" commonly means polynomial in the security parameter ($\lvert \pi \rvert \in \mathrm{poly}(\lambda)$) or polylogarithmic in the statement size ($\lvert \pi \rvert \in \mathrm{polylog}(\lvert x \rvert)$).  
     "Fast" could mean polylogarithmic in the security parameter and statement size ($V(x,\pi) \in O(\mathrm{polylog}(\lambda + \lvert x \rvert)$). <!-- link to Justin's misconception blog post once it's done -->
@@ -90,6 +92,12 @@ Zero-knowledge proofs are named in a fairly self-explanatory way by combining th
 : [Proof](#proof) where the [soundness](#soundness) is [_knowledge_ soundness](#knowledge-soundness).  
 *Properties:* [completeness](#completeness), [knowledge soundness](#knowledge-soundness).
 
+**Probabilistically Checkable Proof (PCP)** { #pcp }
+: 
+
+**Interactive Oracle Proof (IOP)** { #iop }
+: Sometimes referred to as **probabilistically checkable interactive proofs (PCIP)**, this is an interactive variant of PCPs.
+
 **NIWI** { niwi }
 : [Non-Interactive](#non-int) [Witness Indistinguishable](#wi) [proof](#proof).  
 *Properties:* [non-interactivity](#non-int) ("NI"), [witness indistinguishability](#wi) ("WI"), [completeness](#completeness) and [soundness](#soundness) ("proof").
@@ -121,8 +129,7 @@ Zero-knowledge proofs are named in a fairly self-explanatory way by combining th
 *Properties:* Fast verifier _and prover_ time ("S"), transparent/no trusted setup ("T"), [completeness](#completeness) and [_knowledge_ soundness](#knowledge-soundness) ("ArK").
 
 **DV-NIZK**
-: Designated Verifier [NIZK](#nizk); can only be verified by a particular party. This is also referred to as the *private-coin* setting, since the coins (randomness) needed to verify the NIZK are known only to the designated verifier and are thus private.  
-A [_MAC_](../Cryptographic-Primitives/other.md#mac) can be thought of as a DV-NIZK for a key (the witness) corresponding to a message-signature pair (the statement), where the verifier is the party holding the MAC key. This is [zero-knowledge](#zk) since no other party learns the witness from the MAC.
+: Designated Verifier [NIZK](#nizk). 
 
 <!-- **Signature of Knowledge**
 : A generalization of digital signatures. Instead of only proving that the signer has knowledge of a secret key corresponding to a public key, signatures of knowledge can be used to prove the signer knows a witness to some statement $x$. Thus the signature is done with respect to some NP statement.
@@ -160,7 +167,7 @@ Sigma protocols can be made non-interactive via the [Fiat-Shamir transform](../t
     ["On &Sigma;-protocols"](https://cs.au.dk/~ivan/Sigma.pdf) by Ivan Damg&aring;rd  
     ["Sigma Protocols" slides](http://cyber.biu.ac.il/wp-content/uploads/2018/08/WS-19-11-sigma-protocols-winter-school-2019-1.pdf) by Benny Pinkas
 
-!!! example "Sigma protocol: DLog [Schnorr]"
+!!! example "Sigma protocol: DLog [Schnorr'89]"
 
     === "Scheme"
         **Public parameters:** None  
@@ -178,13 +185,28 @@ Sigma protocols can be made non-interactive via the [Fiat-Shamir transform](../t
     === "Properties"
         - HVZK
         - PoK
+        - [Cramer'97] generalizes this to knowledge of a homomorphism preimage
 
 !!! example "Sigma protocol: DDH"
 
     === "Scheme"
 
     === "Properties"
 
+!!! example "Sigma protocol: DLEq [Chaum-Pedersen'92]"
+
+    === "Scheme"
+
+    === "Properties"
+
+!!! example "Sigma protocol: Pedersen opening"
+
+    === "Scheme"
+<!-- https://crypto.stackexchange.com/questions/81236/question-of-proving-the-opening-of-pedersen-commitment#81260 -->
+
+    === "Properties"
+
+
 ## Example Protocols
 
 !!! example "3-coloring [GMW]"

docs/Cryptographic-Primitives/commitments.md

@@ -61,8 +61,68 @@ Besides the basic commitment functionality, there are additional "fancier" types
         === "Further reading"
             For a more detailed description of the scheme, see [https://risencrypto.github.io/Kate/](https://risencrypto.github.io/Kate/).
 
-**Shrinking commitment**
-: <!-- used when we want the pk to be small? -->
-
 **Vector commitment** { #vc }
 : A vector commitment allows one to commit to a vector $\vec{v} = (v_1, \dots, v_n)$ and later individually open elements $v_i$. (Note that a [polynomial commitment](#poly-com) to a polynomial of degree $d$ can be thought of as a vector commitment to $d+1$ points.)
+
+    !!! example "Libert-Yung VC [[LY10]](https://www.iacr.org/archive/tcc2010/59780496/59780496.pdf)"
+
+        === "Scheme"
+            This is a modified version of the original Libert-Yung VC, which was "mercurial", meaning it allowed both "hard" (normal) and "soft" (teasing open to any message a commitment originally made to "no message") openings.
+
+            Let $\mathbb{G},\mathbb{G}_T$ be bilinear groups of prime order $p$ and $e: \mathbb{G} \times \mathbb{G} \rightarrow \mathbb{G}_T$ be a bilinear map. Let $g$ be a random generator of $\mathbb{G}$.
+
+            - $\underline{{\sf Setup}(1^\lambda, q)}$: To set up a VC for vectors of length at most $q$, sample (a trapdoor) $z \stackrel{\$}{\gets} \mathbb{Z}_p^*$ and compute $h_i := g^{z^i}$ for $i = 1, \ldots, q, q+2, \ldots, 2q$.
+
+            - $\underline{{\sf Com}({\sf pp}, \vec{v})}$: To commit to $\vec{v} = (m_1, \ldots, m_q)$, compute
+
+            $$C := h_1^{m_1} h_2^{m_2} \dots h_q^{m_q}$$
+
+            and output $C$ as the commitment.
+
+            - $\underline{{\sf Open}({\sf pp}, i, m_i)}$: Compute $\Lambda_i := \prod_{j=1,j \neq i}^{q} g_{q+1-j+i}^{m_j}$.
+
+            - $\underline{{\sf Vrfy}({\sf pp}, C, i, m_i, \Lambda_i)}$: Given an opening $(i, m_i)$ for the commitment $C$ and an opening proof $\Lambda_i$, a party can verify the correctness of the opening by checking that 
+            
+            $$e(C, h_{q+1-i}) = e(\Lambda_i, g) \cdot e(h_i^{}).$$
+
+
+
+        === "Properties"
+
+        === "Further reading"
+
+    !!! example "(Updatable) VC from CDH [[CF13]](https://eprint.iacr.org/2011/495)"
+
+        === "Scheme"
+            Let $\mathbb{G},\mathbb{G}_T$ be bilinear groups of prime order $p$ and $e: \mathbb{G} \times \mathbb{G} \rightarrow \mathbb{G}_T$ be a bilinear map. Let $g$ be a random generator of $\mathbb{G}$.
+
+            - $\underline{{\sf Setup}(1^\lambda, q)}$: To set up a VC for vectors of length at most $q$, sample (trapdoors) $z_1, \ldots, z_q \stackrel{\$}{\gets} \mathbb{Z}_p$. Compute $h_i := g^{z_i}$ and $h_{i,j} = g^{z_i z_j}$ for $i,j = 1, \ldots, q$ with $j \neq i$. Output ${\sf pp} := (g, \{h_i\}_{i \in [q]}, \{h_{i,j}\}_{i,j \in [q], i \neq j})$.
+
+            - $\underline{{\sf Com}({\sf pp}, \vec{v})}$: To commit to $\vec{v} = (m_1, \ldots, m_q)$, compute
+
+            $$C := h_1^{m_1} h_2^{m_2} \dots h_q^{m_q}$$
+
+            (same as Libert-Yung VC) and output the commitment $C$ and auxiliary information ${\sf aux} := (m_1, \ldots, m_q)$.
+
+            - $\underline{{\sf Open}({\sf pp}, i, m_i, {\sf aux})}$: Compute $\Lambda_i := \prod_{j=1,j\neq i}^{q} h_{i,j}^{m_j} = \prod_{j=1,j\neq i}^{q} \left( h_j^{m_j} \right)^{z_i}$.
+
+            - $\underline{{\sf Vrfy}({\sf pp}, C, i, m_i, \Lambda_i)}$: Given an opening $(i, m_i)$ for the commitment $C$ and an opening proof $\Lambda_i$, a party can verify the correctness of the opening by checking that 
+            
+            $$e(C/h_i^{m_i}, h_i) = e(\Lambda_i, g).$$
+
+            ---
+
+            - $\underline{{\sf Update}({\sf pp}, C, i, m, m')}$: To update the $i$th entry $m$ to $m'$, compute an updated commitment $C' := C \cdot h_i^{m'-m}$ and updating information $U := (m, m', i)$.
+
+            - $\underline{{\sf PfUpdate}({\sf pp}, C, \Lambda_j, m', U)}$: A proof for the opening of position $j$ which was valid w.r.t. $C$ can be updated for $C'$ as follows:
+                - If $j \neq i$, $\Lambda_j' := \Lambda_j \cdot (h_i^{m'-m})^{z_j} = \Lambda_j \cdot h_{j,i}^{m'-m}$.
+                - If $j = i$, the proof $\Lambda_i$ remains unchanged.
+
+        === "Properties"
+
+            - Security holds by the [CDH assumption](../assumptions.md#cdh) in bilinear groups
+            - The scheme is updatable, so the commitment can be updated to reflect an update to one entry of the vector
+
+        === "Further reading"
+
+            - See [the paper](https://eprint.iacr.org/2011/495) for details as well as an additional updatable VC from the [RSA assumption](../assumptions.md#rsa-assumption).

docs/Cryptographic-Primitives/encryption.md

@@ -75,6 +75,8 @@ In the case of a [symmetric (private-key) encryption](#symmetric-enc) scheme, th
         === "Scheme"
             Use a CPA-secure encryption scheme and an adaptively-secure NIZK. Compute $c_1 \gets {\sf Enc}(pk_1, m)$ and $c_2 \gets {\sf Enc}(pk_2, m)$ and use the NIZK to prove $c_1, c_2$ encrypt the same message.
 
+    !!! example "Cramer-Shoup cryptosystem"
+
 **Symmetric (secret-key) encryption** { #symmetric-enc }
 : The same key is used for both decryption and encryption. This means the sender and recipient must somehow securely agree on a secret key; this is usually achieved either via [key agreement](./key-exchange.md#key-agreement) protocols or by encrypting the symmetric key using [public-key encryption](#pke).  
 

docs/Cryptographic-Primitives/other.md

@@ -34,3 +34,12 @@
 
 **Lossy trapdoor function**
 : 
+
+## Accumulators
+
+A **cryptographic accumulator** is a primitive that (succinctly) commits to a set of elements. It should also be possible to provide short proofs of (non-)membership of elements in the set. An accumulator is the unordered sibling of a _vector commitment_.
+
+Some accumulator constructions are described below.
+
+**Merkle tree**
+: 

docs/notation.md

@@ -32,4 +32,6 @@ $\mathbb{Z}_n$
 : The *additive* [group](./general.md#group) of integers modulo $n$, namely $\{0,\dots,n-1\}$. This is a cyclic group, and in fact also a [ring](./general.md#ring)). When $n$ is a prime $p$, all non-identity elements are generators of the group. In that case, the set is also a finite field (since all nonzero elements have multiplicative inverses). 
 
 $\mathbb{Z}_n^\times$ or $\mathbb{Z}_n^*$
-: The *multiplicative* subgroup of $\mathbb{Z}_n$, which consists of all elements of $\mathbb{Z}_n$ that are coprime with $n$. This means that they all have multiplicative inverses modulo $n$ and thus this [group](./general.md#group) is a commutative multiplicative group. When $n$ is a prime $p$, the order of the group is not prime (for $p>3$) and computing the order of any element in the group is efficient if the factorization of $\lvert \mathbb{Z}_p^*\rvert = p-1$ is known. For more number theory/algebra basics, see [David Wu's factsheet](https://www.cs.utexas.edu/~dwu4/courses/fa21/static/algebra.pdf).
+: The multiplicative subgroup of $\mathbb{Z}_n$, which consists of all elements of $\mathbb{Z}_n$ that are coprime with $n$. This means that they all have multiplicative inverses modulo $n$ and thus this [group](./general.md#group) is a commutative multiplicative group. By the definition of [Euler's totient function](https://en.wikipedia.org/wiki/Euler%27s_totient_function), this means that the order of the group is $\lvert \mathbb{Z}_n^* \rvert = \phi(n)$.  
+When $n$ is a prime $p$, $\lvert \mathbb{Z}_p^* \rvert = \phi(p) = p-1$ is not prime (for $p>3$). Thus, computing the order of any element in the group is efficient if the factorization of $p-1$ is known.  
+For more number theory/algebra basics, see [David Wu's factsheet](https://www.cs.utexas.edu/~dwu4/courses/fa21/static/algebra.pdf).

docs/techniques.md

@@ -1,16 +1,14 @@
 # Standard Techniques
 
 **Fiat-Shamir (FS) Transform**
-: A technique which turns any constant-round public-coin [HVZK](./Areas-of-Cryptography/zk.md) protocol (e.g., a [sigma protocol](./Areas-of-Cryptography/zk.md#sigma-protocols)) into a [non-interactive zero-knowledge proof (NIZK)](./Areas-of-Cryptography/zk.md#nizk).
+: A technique which turns any constant-round public-coin [HVZK](./Areas-of-Cryptography/zk.md) protocol (e.g., a [sigma protocol](./Areas-of-Cryptography/zk.md#sigma-protocols)) into a [non-interactive zero-knowledge proof of knowledge (NIZK PoK)](./Areas-of-Cryptography/zk.md#types-of-zero-knowledge-proofs).
 
 **Fujisaki-Okamoto (FO) Transform**
 : 
 
 **RSA Accumulator**
 : 
 
----
-
 **Complexity Leveraging**
 : 
 
@@ -24,4 +22,7 @@
 : 
 
 **Union bound**
+: 
+
+**Naor-Yung Paradigm**
 :