From 3f2c7bd65f5783bbbf9f9d6966fb23d213e52f16 Mon Sep 17 00:00:00 2001 From: jackddouglas Date: Tue, 17 Sep 2024 18:40:26 +0100 Subject: [PATCH] Quartz sync: Sep 17, 2024, 6:40 PM --- content/BLS Threshold.md | 181 ++++++++++++++++++ content/Elliptic Curves.md | 111 +++++++++++ content/Extension fields.md | 2 +- content/KZG.md | 215 ++++++++++++++++++++++ content/Lagrange interpolation formula.md | 8 +- content/Polynomial Commitments.md | 118 ++++++++++++ content/Week 3.md | 22 +++ content/bilinear pairings.md | 27 +++ content/homomorphism.md | 14 ++ content/index.md | 16 ++ content/isomorphism.md | 2 +- 11 files changed, 708 insertions(+), 8 deletions(-) create mode 100644 content/BLS Threshold.md create mode 100644 content/Elliptic Curves.md create mode 100644 content/KZG.md create mode 100644 content/Polynomial Commitments.md create mode 100644 content/Week 3.md create mode 100644 content/bilinear pairings.md create mode 100644 content/homomorphism.md diff --git a/content/BLS Threshold.md b/content/BLS Threshold.md new file mode 100644 index 0000000..bdca5e0 --- /dev/null +++ b/content/BLS Threshold.md @@ -0,0 +1,181 @@ +--- +id: 1726567320-bls-threshold +aliases: + - BLS Threshold +tags: [] +--- + +# BLS Threshold +Threshold cryptography allows a group of parties to jointly perform cryptographic operations such that only a subset (threshold) of the parties is required to collaborate, enhancing both security and availability. The Boneh-Lynn-Shacham (BLS) signature scheme is particularly well-suited for threshold implementations due to its simplicity and the properties of pairing-based cryptography. + +## Overview +A cryptographic algorithm that enables short signatures and efficient aggregation of signatures. Base on [[1726579238-bilinear-pairings|bilinear pairings]] over [[1726567251-elliptic-curves|elliptic curves]]. + +Key Features: +- *Short Signatures* — signatures are elements of an elliptic curve group, resulting in compact representations +- *Signature Aggregation* — multiple signatures can be combined into a single signature, reducing verification overhead +- *Deterministic Signing* — signing process doesn't require randomness, simplifying implementation + +### Mathematical Foundation +Rely on properties of [[1726579238-bilinear-pairings|bilinear pairings]]. + +### Basic BLS Signature Scheme +- Setup + - Choose a bilinear pairing: $e:G_1\times G_2\rightarrow G_T$ + - Select generators $g_1\in G_1,g_2\in G_2$ +- Key Generation + - Private Key: $sk=x\in\Bbb{Z}_r$ + - Public Key: $pk=g_2^x\in G_2$ +- Signing + - Hash the message $m$ to a point $H(m)\in G_1$ + - Compute the signature $\sigma=H(m)^x\in G_1$ +- Verification + - Accept if $e(\sigma,g_2)=e(H(m),pk)$ + +## Threshold Cryptography +### What is it? +A technique where a cryptographic operation is distributed among multiple parties, and a minimum number of parties (threshold $t$) must collaborate to perform the operation. +- *Enhances Security* — no single party holds the complete secret key, reducing risk of key compromise +- *Improves Availability* — system can tolerate up to $n-t$ faulty or compromised parties + +### Threshold Signature Schemes +Allows any subset of at least $t$ out of $n$ participants to produce a valid signature, while subsets smaller than $t$ cannot. +- *Distributed Key Generation* — secret key is never reconstructed; parties hold shares of the key +- *Partial Signatures* — each participant produces a partial signature +- *Signature Reconstruction* — partial signatures are combined to form a complete signatue + +## Threshold BLS Signatures +Combining BLS with threshold cryptography results in *threshold BLS signatures*, which enable a group of parties to collaboratively sign messages using BLS signatures. + +### Core Components +- *Threshold $t$* — minimum number of parties required to produce signature +- *Participants $n$* — total number of parties in system +- *Secret Sharing* — private key is shared among parties using a secret sharing scheme + +### Secret Sharing Schemes +See [[1725904360-shamirs-secret-sharing|Shamir's Secret Sharing]]. + +### Threshold BLS Signature Protocol +- Setup + - *Distributed Key Generation (DKG)* — parties collaboratively generate shares of the private key without revealing it + - *Public Key* — $pk=g_2^x$ is publicly known +- Signing + 1. Partial Signing + - Each party $i$ computes their partial signature: + $$\sigma_i=H(m)^{x_i}$$ + 2. Broadcast Partial Signatures + - Parties share their $\sigma_i$ with the combiner + 3. Signature Reconstruction + - Using [[1725960857-lagrange-interpolation-formula|Lagrange interpolation]], combine $t$ partial signatures to form the full signature: + $$\sigma=\Pi_{i\in S,j\neq1}\sigma_i^{\lambda_i}$$ + where $S$ is the set of participating parties and $\lambda_i$ are Lagrange coefficients: + $$\lambda_i=\Pi_{j\in S,j\neq i}\frac{j}{j-i}$$ +- Verificaiton + - Same as in basic BLS scheme: + $$e(\sigma,g_2)=e(H(m),pk)$$ + +## Advantages of Threshold BLS Signatures +### Efficiency +- *Compact Signatures* — the final signature is the same size as a regular BLS signature +- *Aggregation* — multiple threshold signatures can be aggregated + +### Security +- *Robustness* — the system remains secure even if up to $n-t$ parties are compromised +- *Non-Interactive Signing* — parties can produce partial signatures independently + +### Practicality +- *Simplified Key Management* — no need to reconstruct the secret key at any point +- *Scalability* — suitable for large networks where coordination among all parties is impractical + +## Applications in Cryptography and Computer Science +### Distributed Systems +- *Blockchain Consensus* — used in protocols like *proof of stake* to sign blocks collectively +- *Distributed Key Management* — secure storage and use of cryptographic keys across multiple servers + +### Secure Multi-Party Computation (MPC) +- *Collaborative Signing* — parties compute signatures without revealing their private keys +- *Threshold Encryption* — extending the concept to encryption schemes for secure message decryption by a group + +### Internet Infrastructure +- *Domain Name System Security Extensions (DNSSEC)* — threshold signatures enhance security by distributing trust +- *Certificate Authorities* — prevent single points of failure in issuing digital certificates + +## Implementation Considerations +### Dealing with Malicious Parties +- *Verification of Partial Signatures* — ensure partial signatures are valid before combining +- *Zero-Knowledge Proofs* — parties provide proofs that their shares are correctly computed + +### Communication Overhead +- *Broadcast Channels* — partial signatures need to be shared, requiring efficient communication protocols +- *Threshold Adjustments* — systems should allow for dynamic thresholds to adapt to changing network conditions + +### Key Generation +- *Distributed Key Generation (DKG)* — avoids the need for a trusted dealer; parties jointly generate key shares + +### Liveness and Availability +- *Resilience to Dropouts* — protocol should handle parties becoming unavailable +- *Timeouts and Retries* — implement mechanisms to proceed in the presence of non-responsive parties + +## Security Analysis +### Threshold Unforgeability +- An adversary cannot forge a signature without at least $t$ valid shares +- *Collusion Resistance* — up to $t-1$ colluding parties cannot reconstruct the secret key + +### Robustness Against Attacks +- *Replay Attacks* — each signature is unique to the message, preventing reuse +- *Adaptive Chosen-Message Attacks* — the security of BLS signatures holds under such attacks + +### Assumptions +- *Random Oracle Model* — security proofs often assume the hash function behaves like a random oracle +- *Bilinear Pairing Security* — relies on the hardness of pairing-based cryptographic assumptions + +## Example Walkthrough +### Setup +- Threshold $t=3$, Participants $n=5$ +- Secret Key $x\in\Bbb Z$ +- Sharing Polynomial $f(z)=x+a_1z+a_2z^2$ + +### Key Sharing +Shares: +- Party 1: $x_1=f(1)$ +- Party 2: $x_2=f(2)$ +- Party 3: $x_3=f(3)$ +- Party 4: $x_4=f(4)$ +- Party 5: $x_5=f(5)$ + +### Partial Sharing +Each party computes $\sigma_i=H(m)^{x_i}$ + +### Signature Reconstruction +- Suppose parties 1, 2, and 3 collaborate +- Compute Lagrange coefficients: +$$\lambda_1 = \frac{(0 - 2)(0 - 3)}{(1 - 2)(1 - 3)} = \frac{(-2)(-3)}{(-1)(-2)} = \frac{6}{2} = 3$$ +$$\lambda_2 = \frac{(0 - 1)(0 - 3)}{(2 - 1)(2 - 3)} = \frac{(-1)(-3)}{(1)(-1)} = \frac{3}{-1} = -3$$ +$$\lambda_3 = \frac{(0 - 1)(0 - 2)}{(3 - 1)(3 - 2)} = \frac{(-1)(-2)}{(2)(1)} = \frac{2}{2} = 1$$ +- Combine partial signatures: +$$\sigma = \sigma_1^{\lambda_1} \cdot \sigma_2^{\lambda_2} \cdot \sigma_3^{\lambda_3}$$ + +### Verification +Verify $e(\sigma, g_2)=e(H(m), pk)$ + +## Challenges and Limitations +### Trusted Setup +- Issue: initial key generation may require trust among parties +- Solution: use distributed key generation protocols to eliminate need for trusted dealer + +### Complex Coordination +- Issue: requires coordination among $t$ parties, which may be challenging in large or dynamic networks +- Solution: implement efficient protocols and allow for flexible thresholds + +### Computational Overhead +- Issue: operations like pairing computations are resource-intensive +- Solution: optimise implementations and leverage hardware acceleration + +## References and Further Reading +- “Short Signatures from the Weil Pairing” by Dan Boneh, Ben Lynn, and Hovav Shacham. +- “Threshold Cryptosystems” by Yvo Desmedt. +- “Secure Distributed Key Generation for Discrete-Log Based Cryptosystems” by R. Gennaro, S. Jarecki, H. Krawczyk, and T. Rabin. +- “A Survey of Threshold Cryptography in Blockchain” by M. M. Fernandes et al. +- “An Introduction to Threshold Cryptography” by Victor Shoup. + +*Note: edited ChatGPT 01-preview output was used in the compilation of this document.* diff --git a/content/Elliptic Curves.md b/content/Elliptic Curves.md new file mode 100644 index 0000000..08940de --- /dev/null +++ b/content/Elliptic Curves.md @@ -0,0 +1,111 @@ +--- +id: 1726567251-elliptic-curves +aliases: + - Elliptic Curves +tags: [] +--- + +# Elliptic Curves +A set of points satisfying a specific type of cubic equation, along with a special point at infinity. Over a field $K$, an elliptic curve $E$ can be defined using the *Weierstrass equation*: +$$y^2=x^3+ax+b$$ +where $a,b\in K$ and the curve is *non-singular*, meaning it has no cusps or self-intersections. The discriminant $\Delta=-16(4a^3+27b^2)$ must be non-zero to ensure non-singularity. + +## Group Law on Elliptic Curves +Fascinatingly, elliptic curves form [[Abelian group|abelian groups]] under well-defined addition operations. This group law underscores such curves' cryptographic utility. + +### Point Addition +Given two points $P$ and $Q$ on the curve, their sum $R=P+Q$ is also a point on the curve, defined geometrically: +1. **Case 1:** If $P\neq Q$, draw a line through $P$ and $Q$. This line will intersect the curve at a third point $-R$. Reflect $-R$ over the x-axis to get $R$. +2. **Case 2:** If $P=Q$, draw the tangent line at $P$. This line intersects the curve at $-R$. Reflect to get $R$. + +### Point Doubling +When adding a point to itself $(P+P)$, we use the tangent at $P$. +$$P+P=2P$$ +The slope $m$ of the tangent is: +$$m=\frac{3x^2_P+a}{2y_P}$$ + +### Identity Element +The *point at infinity*, often denoted $\mathcal{O}$, serves as the identity element of the group. For any point $P$: +$$P+\mathcal{O}=P$$ + +## Elliptic Curves over [[finite fields|Finite Fields]] +In cryptography, we often work with elliptic curves over finite fields $\Bbb{F}_p$ (where $p$ is a prime) or $\Bbb{F}_2^m$ (binary fields). Finite fields ensure a finite number of points on the curve, making computation practical. + +### Discrete Logarithm Problem (DLP) +Given points $P$ and $Q=kP$, find $k$. + +The discrete logarithm problem is believed to be very computationally difficult, especially over large finite fields. Thus, a solid foundation for cryptographic schemes. + +## Elliptic Curve Cryptography (ECC) +Uses the properties of elliptic curves to create cryptographic algorithms that are both secure and efficient. + +### Advantages of ECC +- *Stronger security per bit* — ECC offers equivalent security with smaller key sizes than RSA or DSA +- *Performance* — Smaller keys lead to faster computations and reduced storage requirements + +### Common ECC Algorithms +- *Elliptic Curve Diffie-Hellman (ECDH)* — key agreement protocol allowing two parties to establish shared secret over an insecure channel +- *Elliptic Curve Digital Signature Algorithm (ECDSA)* — method for creating digital signatures, ensuring message integrity and authenticity +- *Elliptic Curve Integrated Encryption Scheme (ECIES)* — hybrid encryption scheme combining ECC with symmetric encryption for data confidentiality + +## [[1726579238-bilinear-pairings|Pairings]] on Elliptic Curves +Bilinear maps that take two points on an elliptic curve and output an element in a finite field, enabling advanced cryptographic protocols. + +### Definition +A pairing $e:E[r]\times E[r]\rightarrow\mu_r$ satisfies: +- *Bilinearity* — $e(aP,bQ)=e(P,Q)^{ab}$ +- *Non-degeneracy* — $e(P,Q)\neq 1$ if $P$ and $Q$ are of order $r$ +- *Computability* — there exists an efficient algorithm to compute $e(P,Q)$ + +### Types of Pairings +- *Weil Pairing* +- *Tate Pairing* +- *Optimal Ate Pairing* + +Each have respective applications for which they have better computational advantages and suitability. + +### Applications in Cryptography +- *Identity-Based Encryption (IBE)* — allows the use of arbitrary strings (e.g., email addresses) as public keys +- *Short Signatures* — schemes such as [[1726567320-bls-threshold|BLS]] (Boneh-Lynn-Shacham) enable very short signatures with security based on hardness of certain problems in pairing-friendly groups +- *Attribute-Based Encryption (ABE)* — enables fine-grained access control over encrypted data + +## Common Curves +Standardisation bodies and cryptographic libraries often use specific curves optimised for security and performance. + +### NIST Curves +- *P-256, P-384, P-521* — curves recommended by NIST with prime field sizes of 256, 384, and 521 bits + +### SEC Curves +- *secp256k1* — used extensively in cryptocurrencies such as Bitcoin + +### Montgomery and Edwards Curves +- *Curve25519* — a Montgomery curve known for its performance and security, used in protocols such as TLS and SSH +- *Edwards Curves (e.g., Ed25519)* — offer faster arithmetic and simpler, more secure implementations + +### Pairing-Friendly Curves +- *Barreto-Naehrig (BN) Curves* — designed to optimise the efficiency of pairings, suitable for cryptographic protocols requiring bilinear maps +- *BLS12-381*: used in Ethereum 2.0 for its efficient pairings and high security level + +## Implementation Considerations +### Field Arithmetic +Efficient implementation requires optimised algorithms for field operations: +- Modular addition/subtraction +- Modular multiplication +- Modular inversion + +### Scalar Multiplication +Computing $kP$ efficiently is crucial: +- *Double-and-Add Algorithm* +- *Montgomery Ladder* — offers protection against certain side-channel attacks + +### Security Considerations +- *Side-Channel Attacks* — implementations must protect against timing and power analysis attacks +- *Curve Selection* — choosing curves with well-understood security properties is essential + +## References and Further Reading +- “An Introduction to Mathematical Cryptography” by Hoffstein, Pipher, and Silverman. +- “Guide to Elliptic Curve Cryptography” by Hankerson, Vanstone, and Menezes. +- Standards for Efficient Cryptography (SEC) documents for detailed specifications on various curves. +- Research papers on Pairing-Based Cryptography by Boneh, Lynn, and Shacham. + +*Note: edited ChatGPT 01-preview output was used in the compilation of this document.* diff --git a/content/Extension fields.md b/content/Extension fields.md index 6f5c2ba..feed4af 100644 --- a/content/Extension fields.md +++ b/content/Extension fields.md @@ -51,7 +51,7 @@ Degree of an extension $E/F$, denoted $[E:F]$, is the dimension of $E$ as a vect - Solving Polynomial Equations - Extension fields allow us to find roots of polynomials that don't have roots in the base field - Constructibility Problems - - In geometry, extension fields help determine which lengths are constructible with compass and straightedge + - In geometry, extension fields help determine which lengths are constructible with compass and straight-edge - [[Galois Theory]] - Uses field extensions to study the solvability of polynomial equations and the relationship between roots of polynomials - Algebraic Number Theory diff --git a/content/KZG.md b/content/KZG.md new file mode 100644 index 0000000..edee2bd --- /dev/null +++ b/content/KZG.md @@ -0,0 +1,215 @@ +--- +id: 1726567313-kzg +aliases: + - KZG +tags: [] +--- + +# KZG +A type of polynomial commitment scheme that enables a prover to commit to a polynomial and later prove the correctness of its evaluations at specific points efficiently. KZG commitments are ntoable for their constant-size commitments and proofs (agnostic of polynomial degree), making them highly efficient for cryptographic applications such as zk-SNARKs and blockchain technologies. + +## Overview +KZG commitments allow a prover to: +- *Commit* to a polynomial $f(x)$ of degree $d$ with a single group element $C$ +- *Open* the commitment at any point $s$ by providing a proof $\pi$ that the evaluation $y=f(s)$ is correct +- *Verify* the proof efficiently, with the verifier performing computations independent of $d$ + +## Mathematical Foundations +Builds on: +- [[1725898229-polynomial-arithmetic|Polynomial Arithmetic]] +- [[1726567251-elliptic-curves#elliptic-curve-cryptography-ecc|Elliptic Curve Cryptography]] +- [[1726567251-elliptic-curves#pairings-on-elliptic-curves|Pairings]] + +### Bilinear Pairings +A [[1726579238-bilinear-pairings|bilinear pairing]] is a map: +$$e:G_1\times G_2 \rightarrow G_T$$ + +where: +- $G_1,G_2,$ and $G_T$ are cyclic groups of prime order $r$ +- The pairing $e$ has the following properties: + - *Bilinearity* — $e(aP,bQ)=e(P,Q)^{ab}$ for all $P\in G_1$, $Q\in G_2$, $a,b \in \Bbb{Z}_r$ + - *Non-degeneracy* — $e(P,Q)\neq 1$ if $P$ and $Q$ are generators + - *Computability* — there exists an efficient algorithm to compute $e(P,Q)$ + +## The KZG Commitment Scheme +Involves the following algorithms: +- *Setup* +- *Commit* +- *Open* +- *Verify* + +### Setup +A trusted party generates public parameters using a secret $\tau\in\Bbb{F}_r$, where $\Bbb{F}_r$ is a finite field of prime order $r$. + +Parameters: +- $G$ and $H$ are generators of $G_1$ and $G_2$ respectively +- $\{G^{\tau^i}\}_{i=0}^d$: elements in $G_1$, precomputed powers of $\tau$ +- $H^\tau$ is an element in $G_2$ + +Outputs: +- Public parameters: $PP=(G,H,\{G^{\tau^i}\}_{i=0}^d,H^\tau)$ +- Secret $\tau$ is discarded or securely erased + +### Commit +Given a polynomial $f(x)=\sum_{i=0}^d{f_ix^i}$, the prover computes the commitment $C$ as: +$$C=\sum_{i=0}^d{f_iG^{\tau^i}}\in G_1$$ + +Alternatively, using polynomial notation: +- Represent $f(\tau)$ as an element in $G_1$: + - $C=G^{f(\tau)}$ + +This uses the [[1726580434-homomorphism|homomorphism]] between polynomials evaluated at $\tau$ and group elements. + +### Open +To prove that $y=f(s)$ for some $s\in \Bbb{F}_\tau$, the prover computes a proof $\pi$ as follows: +1. Compute the *witness polynomial*: +$$w(x)=\frac{f(x)-y}{x-s}$$ +2. Compute the proof $\pi$: +$$\pi=\text{Commit}(w)=G^{w(\tau)}\in G_1$$ + +This works because $f(x)-y=(x-s)w(x)$, so $w(\tau)=\frac{f(\tau)-y}{\tau-s}$. + +### Verify +The verifier checks the proof using the pairing operation: +1. Compute $e(C-G^y,H)$ +2. Compute $e(\pi,H^\tau-H^s)$ +3. Check if $e(C-G^y,H)=e(\pi,H^{\tau-s})$ + +Since $H^{\tau-s}=H^\tau\cdot(H^s)^{-1}$, this can be computed efficiently. + +Alternatively, the verifier checks: +$$e(C-G^y,H)=e(\pi,H^{\tau-s})$$ + +## Security Analysis +### Correctness +If both prover and verifier follow the protocol, the verification will succeed. + +#### Proof Sketch +From the prover's side: +$$\pi=G^{w(\tau)}=G^{\frac{f(\tau)-y}{\tau-s}}$$ + +From the verifier's side: +$$e(C-G^y,H)=e(G^{f(\tau)-y},H)=e(G^{f(\tau)-y},H)$$ +$$e(\pi, H^{\tau-s})=e(G^{\frac{f(\tau)-y}{\tau-s}},H^{\tau-s})=e(G^{f(\tau)-y},H)$$ + +Thus, both sides are equal. + +### Binding +The binding property relies on the [[1726567251-elliptic-curves#discrete-logarithm-problem-dlp|discrete logarithm problem]] and the assumption that the prover cannot find two different polynomials $f(x)$ and $f'(x)$ such that $f(\tau)=f'(\tau)$, unless $f(x)=f'(x)$. + +#### Security Assumption +- *Computational Diffie-Hellman (CDH) Problem* — hardness of computing $G^{ab}$ given $G^a$ and $G^b$ +- *Knowledge of Coefficient (KoC)* — the commitment $C$ binds the prover to a specific polynomial $f(x)$ + +### Soundness +The prover cannot produce a vlaid proof $\pi$ for an incorrect evaluation $y$ without solving a hard problem in the underlying group. + +## Trusted Setup and Its Mitigation +### Trusted Setup +- *Vulnerability* — if the secret $\tau$ is known to the prover, she can create fake proofs +- *Mitigation* — use a *Multi-Party Computation (MPC) ceremony* where multiple participants contribute to the generation of $\tau$ without any single party knowing it entirely + +### MPC Ceremony +- Each participant $i$ picks a secret $\tau_i$ +- The combined secret is $\tau=\Pi_i\tau_i$ +- As long as one participant keeps their $\tau_i$ secret, the overall $\tau$ remains secure + +## Efficiency and Practicality +### Constant-Size Commitments and Proofs +Both the commitment $C$ and the proof $\pi$ are single elements in $G_1$, regardless of the polynomial's degree. + +### Verification Efficiency +- The verifier performs a small number of pairing operations, independent of the polynomial's degree +- Pairing operations are computationally intensive but practical with modern cryptographic libraries + +### Prover Efficiency +- The prover's work involves computing $w(x)$ and exponentiations +- Efficient algorithms like [[1725903044-fast-fourier-transform|Fast Fourier Transforms (FFT)]] can optimise polynomial operations when dealing with large degrees. + +## Applications of KZG Commitments +### zk-SNARKs +- KZG commitments are used in constructing *Succinct Non-Interactive Arguments of Knowledge* +- Protocols like *Plonk* and *Sonic* leverage KZG commitments for efficient zero-knowledge proofs + +### Blockchain Technologies +- *Ethereum 2.0* uses KZG commitments in *danksharding* proposal for scalable data availability proofs +- *Plonk Protocol* is a universal SNARK protocol that uses polynomial commitments for efficient proof generation and verification + +### Verifiable Computation +- Clients can verify that a server correctly performed computations on polynomials (e.g., evaluations, integrations) without redoing the computations. + +## Example Walkthrough +A simple example to illustrate how KZG commitments operate. + +### Setup +- Let $r=23$, a small prime for simplicity +- The trusted setup selects $\tau=5$ +- Compute $G^{\tau^i}$ for $i=0$ to $d$ (let's say $d=2$) + +### Prover's Commitment +- Polynomial: $f(x)=3x^2+2x+1$ +- Commitment: $C=f(\tau)\cdot G=f(5)\cdot G=(3\cdot5^2+2\cdot5+1)\cdot G=(75+10+1)\cdot G=86\cdot G$ + +### Prover's Proof of Evaluation at $s=2$ +- Compute $y=f(2)=3\cdot4+2\cdot2+1=12+4+1=17$ +- Compute witness polynomial: +$$w(x)=\frac{f(x)-y}{x-s}=\frac{f(x)-17}{x-2}$$ +- Calculate $w(\tau)$ +$$w(5)=\frac{f(5)-17}{5-2}=\frac{86-17}{3}=\frac{69}{3}=23$$ +- Compute proof: +$$\pi=w(\tau)\cdot G=23\cdot G$$ + +### Verifier's Check +- Compute $C-y\cdot G=(86-17)\cdot G=69\cdot G$ +- Compute $H^{\tau-s}=H^{5-2}=H^3$ +- Verify: +$$e(69\cdot G,H)=e(23\cdot G,H^3)$$ + +Since $e(a\cdot G,H)=e(G,H)^a$: + +$e(G,H)^69=e(G,H^3)^23=(e(G,H)^3)^23=e(G,H)^69$ + +Verification succeeds! + +## Implementation Considerations +### Choice of Elliptic Curves +- *Pairing-Friendly Curves* — curves such as BLS12-381 or BN254 are chosen for their efficiency in pairing operations +- *Security Level* — select curves that provide at least 128-bit security + +### Handling Large Polynomials +- *FTT Optimisation* — use FFTs over finite fields for efficient polynomial opertaions +- *Multi-Exponentiation* — optimise exponentiations involving multiple bases + +### Side-Channel Protections +- Implement constant-time algorithms to prevent timing attacks +- Use blinding techniques to protect against side-channel leakage + +## Advantages and Limitations +### Advantages +- *Constant-size proofs* — independent of the polynomial's degree +- *Efficiency* — fast verification for applications requiring scalability +- *Compatibility* — integrates well with existing cryptographic protocols + +### Limitations +- *Trusted Setup* — requires a secure generation of the secret $\tau$ +- *Pairing Operations* — computationally intensive, though practical with optimisation +- *Assumptions* — security depends on the hardness of specific problems in pairing-friendly groups + +## Variants and Extensions +### Batched Proofs +Provers can compute a single proof for multiple evaluations to improve efficiency + +### Aggregation +Aggregate multiple commitments and proofs to reduce communication overhead + +### Transparent Setups +Research into schemas that avoid trusted setups, though they may sacrifice some efficiency. + +## References and Further Reading +- “Constant-Size Commitments to Polynomials and Their Applications” by Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg. +- “Pairing for Beginners” by Craig Costello. +- Ethereum Improvement Proposals (EIPs) related to KZG commitments and data availability. +- “Plonk: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge” by Ariel Gabizon, Zachary J. Williamson, and Oana Ciobotaru. +- “Why and How zk-SNARK Works: Definitive Explanation” by Vitalik Buterin. + +*Note: edited ChatGPT 01-preview output was used in the compilation of this document.* diff --git a/content/Lagrange interpolation formula.md b/content/Lagrange interpolation formula.md index 317fda8..b75aff2 100644 --- a/content/Lagrange interpolation formula.md +++ b/content/Lagrange interpolation formula.md @@ -10,9 +10,7 @@ A mathematical method used to reconstruct a polynomial given a set of points. In The general form of the Lagrange interpolation formula is: -``` -f(x) = Σ(i=1 to n) yi * Li(x) -``` +$$f(x) = Σ(i=1 to n) yi * Li(x)$$ Where: - `f(x)` is the reconstructed polynomial @@ -41,9 +39,7 @@ In the [[1725904360-shamirs-secret-sharing|Shamir's Secret Sharing]] code, this ``` This calculates: - ``` - Li(x) = Π(j≠i) (x - xj) / (xi - xj) - ``` + $$Li(x) = Π(j≠i) (x - xj) / (xi - xj)$$ 3. The `yi` term is multiplied in: ```rust diff --git a/content/Polynomial Commitments.md b/content/Polynomial Commitments.md new file mode 100644 index 0000000..3a2ec9c --- /dev/null +++ b/content/Polynomial Commitments.md @@ -0,0 +1,118 @@ +--- +id: 1726567296-polynomial-commitments +aliases: + - Polynomial Commitments +tags: [] +--- + +# Polynomial Commitments +Cryptographic primitives that enable a prover to commit to a polynomial $f(x)$ and later reveal evaluations $f(s)$ at specific points $s$, with assurance to the verifier that the evaluations are correct, without revealing the entire polynomial. Essential in [[zero-knowledge proofs]], [[verifiable computation]], and blockchain technologies. + +## Overview +Polynomial commitment schemes allow a prover to commit to a polynomial in such a way that: +- The commitment is *binding*: once committed, the prover cannot change the polynomial without being detected +- The commitment is *hiding* (scheme-dependent): the committed polynomial remains secret until the prover decides to reveal it +- The prover can efficiently prove to a verifier that a given value is the correct evaluation of the polynomial at a specific point + +They consist of the following algorithms: +- *Setup* — generates public parameters for the scheme +- *Commit* — commits to a polynomial $f(x)$ +- *Open* — produces a rpoof that $f(s)=y$ without revealing $f(x)$ +- *Verify* — checks the proof to confirm that $f(s)=y$ holds for the committed polynomial + +## Applications +Essential for constructing efficient cryptographic protocols where the size of the proof and the verification time are independent of the degree of the polynomial or size of the data. +- *zk-SNARKs* — used in privacy-preserving cryptocurrencies like Zcash +- *Verifiable Computation* — allows clients to outsource computation to servers and verify results efficiently +- *Blockchain Scaling Solutions* — used in schemes like [[data availability sampling]] in Ethereum 2.0 to ensure data availability without downloading all the data (and increasingly in L2 rollups) + +## Properties +- *Correctness* — if prover and verifier follow protocol honestly, verifier should accept valid proofs +- *Binding* — should be computationally infeasible for the prover to find two different polynomials $f(x)$ and $f'(x)$ that produce the same commitment +- *Hiding (sometimes)* — in some schemes, commitment hides the polynomial, providing privacy until the prover chooses to reveal it +- *Efficiency* + - *Compactness* — size of commitment and proofs should be small, ideally constant-sized regardless of polynomial's degree + - *Fast Verification* — verifier's work should be minimal, enabling practical development + +## Types of Commitment Schemes +### Kate Commitments ([[1726567313-kzg|KZG]] Commitments) +- *Setup* — trusted setup generates public parameters, including sequence $\{\tau^i\}$ for $i=0$ to $d$, where $\tau$ is a secret +- *Commit* — given polynomial $f(x)=\sum^d_{i=0}{f_ix^i}$, the commitment is: +$$C=\sum_{i=0}^d{f_iG^{\tau^i}}$$ +where $G$ is a generator of an elliptic curve group. +- *Open* — to prove that $f(s)=y$, prover computes a proof $\pi$ based on the polynomial's evaluation at $s$. +- *Verify* — verifier checks pairing equations to confirm proof's validity + +#### Use of Pairings +KZG commitments rely on [[bilinear pairings]] on [[1726567251-elliptic-curves|elliptic curves]], which enable efficient verification through pairing-based equations. +- *Bilinear Pairing* — a map $e:G_1\times G_2\rightarrow G_T$ satisfying bilinearity, non-degeneracy, and computability +- *Verification Equation* — $e(C-y\cdot G, H)=e(\pi, G-s\cdot H)$, here, $H$ is another generator, and $s$ is the evaluation point + +#### Advantages +- *Constant-size commitments and proofs* — independent of the polynomial's degree +- *Efficient Verification* — fast verification using pairings + +#### Drawbacks +- *Trusted setup* — requires a secure generation of secret $\tau$ +- *Security assumptions* — relies on hardness of [[1726567251-elliptic-curves#discrete-logarithm-problem-dlp|Discrete Logarithm Problem]] and *Computational Diffie-Hellman Problem* in pairing groups. + +### Other Schemes +#### Pedersen Commitments +A hiding and binding commitment scheme based on discrete logarithms. Less efficient for polynomial commitments due to linear-sized proofs. + +#### Bulletproofs +Non-interactive zk proofs that support logarithmic-sized range proofs that can be adapted for polynomial commitments. + +Advantages +- Doesn't require trusted setup + +Drawbacks +- Verification is more computationally intensive compared to KZG commitments + +#### DARK (discrete-log-based Accumulators and RPCs) +Uses groups of unknown order (such as RSA groups) to achieve polynomial commitments without pairings. + +Advantages +- No need for pairings + +Drawbacks +- Less efficient +- Requires groups of unknown order + +## Applications +### Zero-Knowledge Proofs +- Used in constructing zk-SNARKs and zk-STARKs, enabling efficient and succinct proofs that a computation was performed correctly without revealing the computation's inputs or polynomial itself. + +### Verifiable Computation +- Clients can verify that a server correctly performed computations on polynomials (e.g., evaluations, integrations) without redoing the computations. + +### Blockchain Technologies +- *Ethereum 2.0* uses KZG commitments in *danksharding* proposal for scalable data availability proofs +- *Plonk Protocol* is a universal SNARK protocol that uses polynomial commitments for efficient proof generation and verification + +## Connection to [[1725960857-lagrange-interpolation-formula|Lagrange Interpolation]] +Any polynomial $f(x)$ of degree $d$ can be uniquely distributed by $d+1$ evaluations at distinct points, which is fundamental in constructing and verifying polynomial commitments. + +## Implementation Considerations +### Trusted Setup +- *Multi-Party Computation (MPC)* — to mitigate trust issues, setups can be performed via MPC ceremonies where multiple parties contribute randomness, ensuring that as long as one party is honest, the setup remains secure + +### Efficiency Optimisations +- *Batch verification* — verifying multiple proofs simultaneously to reduce computational overhead +- *Parallelisation* — leveraging parallel computing for operations like pairings and exponentiations + +### Security Considerations +- *Security Assumptions* — based on well-studied problems such as discrete logarithm problem in elliptic curve groups +- *Side-Channel Attacks* — implementations must protect against timing attacks and other side-channel exploits + +### Choice of Curves +- *Pairing-Friendly Curves* — curves such as BN256 or BLS12-381 are chosen for efficiency in pairing operations + +## References and Further Reading +- “Polynomial Commitments” by Aniket Kate, Gregory M. Zaverucha, and Ian Goldberg. +- “A Practical Introduction to Pairings on Elliptic Curves” by Craig Costello. +- “Why and How zk-SNARK Works: Definitive Explanation” by Vitalik Buterin. +- Ethereum Research and EIPs related to polynomial commitments and KZG schemes. +- “A Decade of Lattice Cryptography” by Chris Peikert, for alternative approaches in cryptography. + +*Note: edited ChatGPT 01-preview output was used in the compilation of this document.* diff --git a/content/Week 3.md b/content/Week 3.md new file mode 100644 index 0000000..097709b --- /dev/null +++ b/content/Week 3.md @@ -0,0 +1,22 @@ +--- +id: 1726567221-week-3 +aliases: + - Week 3 +tags: [] +--- + +# Key Ideas +- [[1726567251-elliptic-curves|Elliptic Curves]] + - [[1726567251-elliptic-curves#pairings-on-elliptic-curves|Pairings]] + - [[1726567251-elliptic-curves#common-curves|Common Curves]] +- [[1726567296-polynomial-commitments|Polynomial Commitments]] +- [[1726567313-kzg|KZG]] +- [[1726567320-bls-threshold|BLS Threshold]] + +# Exercises +- Implement [[1726567313-kzg|KZG]] commitment, proof + +# References +- https://github.com/pluto/ronkathon/blob/main/src/curve/README.md +- https://github.com/pluto/ronkathon/blob/main/src/kzg/README.md +- Proofs Args (CH 15) diff --git a/content/bilinear pairings.md b/content/bilinear pairings.md new file mode 100644 index 0000000..ee9ded0 --- /dev/null +++ b/content/bilinear pairings.md @@ -0,0 +1,27 @@ +--- +id: 1726579238-bilinear-pairings +aliases: + - bilinear pairings +tags: [] +--- + +# bilinear pairings +Maps that take two points on an elliptic curve and output an element in a finite field, enabling advanced cryptographic protocols. + +### Definition +A pairing $e:E[r]\times E[r]\rightarrow\mu_r$ satisfies: +- *Bilinearity* — $e(aP,bQ)=e(P,Q)^{ab}$ +- *Non-degeneracy* — $e(P,Q)\neq 1$ if $P$ and $Q$ are of order $r$ +- *Computability* — there exists an efficient algorithm to compute $e(P,Q)$ + +### Types of Pairings +- *Weil Pairing* +- *Tate Pairing* +- *Optimal Ate Pairing* + +Each have respective applications for which they have better computational advantages and suitability. + +### Applications in Cryptography +- *Identity-Based Encryption (IBE)* — allows the use of arbitrary strings (e.g., email addresses) as public keys +- *Short Signatures* — schemes such as [[1726567320-bls-threshold|BLS]] (Boneh-Lynn-Shacham) enable very short signatures with security based on hardness of certain problems in pairing-friendly groups +- *Attribute-Based Encryption (ABE)* — enables fine-grained access control over encrypted data diff --git a/content/homomorphism.md b/content/homomorphism.md new file mode 100644 index 0000000..69b5f5e --- /dev/null +++ b/content/homomorphism.md @@ -0,0 +1,14 @@ +--- +id: 1726580434-homomorphism +aliases: + - homomorphism +tags: [] +--- + +# homomorphism +A structure-preserving map between two algebraic structures of the same type (e.g., two rings, two groups, two fields). While their elements may appear completely different, results on one system often apply to the other. Homomorphism enables useful simplifications. For example, proving homomorphism between two structures enables the mapping of known behaviours and characteristics from one system onto the other. + +## Definition +A map $f:A\rightarrow B$ between two sets, $A, B$ have the same structure such that, if $\cdot$ is an operation of the structure, then: +$$f(x\cdot y)=f(x)\cdot f(y)$$ +for every pair $x,y$ of elements of $A$. diff --git a/content/index.md b/content/index.md index d303d0d..5cc12bb 100644 --- a/content/index.md +++ b/content/index.md @@ -53,3 +53,19 @@ If you'd like to follow along, you may navigate to [this Notion page](https://ww - https://github.com/pluto/ronkathon/tree/main/src/codes - https://github.com/pluto/ronkathon/blob/main/math/polynomial.sage - Moonmath Manual Polynomial Arithmetic + +### [[Week 3]] +- [[1726567251-elliptic-curves|Elliptic Curves]] + - [[1726567251-elliptic-curves#pairings-on-elliptic-curves|Pairings]] + - [[1726567251-elliptic-curves#common-curves|Common Curves]] +- [[1726567296-polynomial-commitments|Polynomial Commitments]] +- [[1726567313-kzg|KZG]] +- [[1726567320-bls-threshold|BLS Threshold]] + +#### EXERCISES +- Implement [[1726567313-kzg|KZG]] commitment, proof + +#### REFERENCES +- https://github.com/pluto/ronkathon/blob/main/src/curve/README.md +- https://github.com/pluto/ronkathon/blob/main/src/kzg/README.md +- Proofs Args (CH 15) diff --git a/content/isomorphism.md b/content/isomorphism.md index a5f7188..49d99e7 100644 --- a/content/isomorphism.md +++ b/content/isomorphism.md @@ -34,7 +34,7 @@ Fundamental concept in abstract algebra. Allow us to identify when two seemingly ## Isomorphism Theorems Several important isomorphism theorems in algebra that relate quotient structures to substructures: -- First Isomorphism Theorem (for groups): $G/\text{ker}(\varphi)\cong\text{im}(\varphi)$ for any homomorphism $\varphi$ +- First Isomorphism Theorem (for groups): $G/\text{ker}(\varphi)\cong\text{im}(\varphi)$ for any [[homomorphism]] $\varphi$ - Similar theories exist for [[rings]] and other algebraic structures ## Properties Preserved by Isomorphisms