-
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
d9ea5fc
commit 3f2c7bd
Showing
11 changed files
with
708 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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.* |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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.* |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.