github/vac.dev
1
1
Fork 0
mirror of https://github.com/vacp2p/vac.dev.git synced 2026-01-10 15:18:36 -05:00
Code Issues Packages Projects Releases Wiki Activity

chore: Fix typos (#157)

Browse Source
This commit is contained in:
omahs
2025-02-03 11:08:57 +01:00
committed by GitHub
parent c2c00209d0
commit fba3a2d7c3
2 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
rlog/2024-08-23-state-separation.mdx
View File

@@ -721,7 +721,7 @@ processes that uphold the system’s security and privacy standards.
### Use case: How to use the Pedersen hash to create the UTXO commitment
---
As mentioned in the [UTXOs in private exections section](#pe), the user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs
As mentioned in the [UTXOs in private executions section](#pe), the user broadcasts the encrypted UTXOs to the network, along with a commitment to the output UTXOs
using **Pedersen hashes**. The Pedersen hash is used to create the UTXO commitment. The Pedersen hash is a homomorphic commitment scheme that allows secure commitments
while maintaining privacy and enabling proofs of correctness in transactions. The commitment formula is as follows:
@@ -1155,7 +1155,7 @@ It guarantees that public and private executions remain equitable, with the tota
The mechanism employs **MPC protocols** to perform computations privately, **ZKPs** to verify correctness, and **cryptographic protocols**
to secure data during synchronization. This ensures a consistent and fair environment for all users, regardless of their chosen privacy level. Currently,
this feature is under development and review for potential inclusion depending on the research output and compability.
this feature is under development and review for potential inclusion depending on the research output and compatibility.
@@ -1220,7 +1220,7 @@ model as the blockchain grows and evolves.
[1] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. Retrieved from https://bitcoin.org/bitcoin.pdf
[2] Sanchez, F. (2021). Cardano’s Extended UTXO accounting model. Retrived from https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/
[2] Sanchez, F. (2021). Cardano’s Extended UTXO accounting model. Retrieved from https://iohk.io/en/blog/posts/2021/03/11/cardanos-extended-utxo-accounting-model/
[3] Morgan, D. (2020). HD Wallets Explained: From High Level to Nuts and Bolts. Retrieved from https://medium.com/mycrypto/the-journey-from-mnemonic-phrase-to-address-6c5e86e11e14

20
rlog/2024-10-15-vac101-fiat-shamir.mdx
View File

@@ -21,7 +21,7 @@ The Prover tries to convince the Verifier of a given claim.
For example, the Prover may want to convince the Verifier that she owns a specific Unspent Transaction Output (UTXO);
that is, the Prover possesses the ability to spend the UTXO.
In many instances, there is information that the Prover does not wish to reveal to the Verifier.
In our example, it is critical that the Prover does not provide the Verifier with the spending key associated to her UTXO.
In our example, it is critical that the Prover does not provide the Verifier with the spending key associated with her UTXO.
In addition to the Prover's claim and secret data, there is additional data, public parameters, that the claimed statement is expressed in terms of.
The public parameters can be thought of as the basis for all similar claims.
@@ -53,7 +53,7 @@ In particular, the protocol has the following framework:
These three messages form the protocol's transcript: $(\mathsf{commitment}, \mathsf{challenge}, \mathsf{response})$.
The Verifier uses all three of these messages to validate the Prover's original claim.
The Verifier's challenge should be selected uniform random from all possible challenges.
Based on this selection, a dishonest Prover can only convince the the Verifier with a negligible probability.
Based on this selection, a dishonest Prover can only convince the Verifier with a negligible probability.
### The Schnorr Protocol
@@ -147,28 +147,28 @@ The properties of $\mathsf{Hash}$ fixes the generator $g$ and the Prover's state
## Improper use of the Fiat-Shamir heuristic
The Fiat-Shamir heuristic appears to be a fairly straight-forward technique to implement.
The Fiat-Shamir heuristic appears to be a fairly straightforward technique to implement.
However, a subtle but serious issue that can occur in the application of the Fiat-Shamir heuristic has been a point of discussion for the past few years.
The issue concerns what messages are included in the hash.
In particular, are the public parameters used to compute the hash value?
Bernhard et al. [8](https://eprint.iacr.org/2016/771.pdf) provide a discussion of Fiat-Shamir heuristic resticted to $\Sigma$-protocols.
Bernhard et al. [8](https://eprint.iacr.org/2016/771.pdf) provide a discussion of Fiat-Shamir heuristic restricted to $\Sigma$-protocols.
In particular, Bernhard et al. discuss the pitfalls of the weak Fiat-Shamir heuristic.
Recall that the strong Fiat-Shamir heuristic requires that the public parameters are included in the calculations of the Verifier's messages while the weak version does not.
The inclusion of the public parameters in the hash evaluations fix these public values for the entire protocol.
The inclusion of the public parameters in the hash evaluations fixes these public values for the entire protocol.
This means that the Prover cannot retroactively change them.
The issues with the differences in the variants of the Fiat-Shamir heuristics has persisted since Bernhard et al.'s paper.
In recent years, auditors from [Trail of Bits](https://www.trailofbits.com/) and [OpenZepellin](https://www.openzeppelin.com/) have
In recent years, auditors from [Trail of Bits](https://www.trailofbits.com/) and [OpenZeppelin](https://www.openzeppelin.com/) have
released blogs ([9](https://blog.trailofbits.com/2022/04/13/part-1-coordinated-disclosure-of-vulnerabilities-affecting-girault-bulletproofs-and-plonk/),
[10](https://blog.trailofbits.com/2022/04/14/the-frozen-heart-vulnerability-in-giraults-proof-of-knowledge/),
[11](https://blog.trailofbits.com/2022/04/15/the-frozen-heart-vulnerability-in-bulletproofs/), [12](https://blog.trailofbits.com/2022/04/18/the-frozen-heart-vulnerability-in-plonk/), [13](https://blog.openzeppelin.com/the-last-challenge-attack))
and papers ([14](https://eprint.iacr.org/2023/691), [15](https://eprint.iacr.org/2024/398))
describing specific vunerabilities in zero-knowledge papers and repositories associated to the use of the weak Fiat-Shamir heuristic.
describing specific vulnerabilities in zero-knowledge papers and repositories associated with the use of the weak Fiat-Shamir heuristic.
Trail of Bits coined the term **FROZEN Heart** to describe the use of weak Fiat-Shamir heuristic.
Frozen comes from the phrase "FoRging Of ZEro kNowledge proofs",
and Fiat-Shamir is the "heart" of transforming an interactive protocol to noninteractive procotol.
and Fiat-Shamir is the "heart" of transforming an interactive protocol to noninteractive protocol.
Now, we examine how weak Fiat-Shamir affects the Schnorr protocol and Chaum-Pedersen protocol.
@@ -180,7 +180,7 @@ the second where we include the public parameter $g$ but not the Prover's claim
Since we omit the generator $g \in \mathbb{G}$ from the computation for the message $c$ in our first approach,
then $c = \mathsf{Hash}(X||T)$.
Now, a malicious Prover can completes the transcript for the Schnorr protocol by selecting any $z \in_R \mathbb{Z}_p$.
Now, a malicious Prover can complete the transcript for the Schnorr protocol by selecting any $z \in_R \mathbb{Z}_p$.
Since, $g$ is not fixed as it was not included in the computation of $c$.
But, the malicious Prover needs the transcript $(T,c,z)$ to satisfy $g^z = TX^c$.
Hence, the malicious Prover can compute the generator $g = (TX^c)^{z^{-1}}.$
@@ -199,7 +199,7 @@ As such, a malicious Prover can generate values for $U,V,W$, and $g$ that satisf
In the case of a malicious Prover, $T$ and $S$ are randomly group elements instead of being computed using a value $t$ that the Prover selected.
This means a malicious Prover must randomly select the value $z$ as well.
Given the values that have been fixed so far, each of the Verifier's identities consist of two unknowns.
Given the values that have been fixed so far, each of the Verifier's identities consists of two unknowns.
Hence, it is necessary to select one of these unknowns from each identity so that a malicious Prover can compute the last value.
For instances, suppose that the malicious Prover randomly selects $V$ and $W$.
The malicious Prover can compute $g = (T V^c)^{1/z}$ and $V = (SW^c)^{1/z}$.