sp1-stark
Activity
- Latest release
- 8mo ago
- Total releases
- 43
- Cadence
- ~6 days
- Last 12 months
- 3
Details
- License
- MIT OR Apache-2.0
- First release
- Aug 27, 2024
| Version | Released | |
|---|---|---|
5.2.4
unknown
|
5.2.4
unknown
Dependencies (26)
+ 18 more |
|
5.2.3
unknown
|
5.2.3
unknown
Dependencies (26)
+ 18 more |
|
5.2.2
unknown
|
5.2.2
unknown
Dependencies (26)
+ 18 more |
|
5.2.1
unknown
|
5.2.1
unknown
Dependencies (27)
+ 19 more |
|
5.2.0
unknown
|
5.2.0
unknown
Dependencies (27)
+ 19 more |
|
5.1.1
unknown
|
5.1.1
unknown
Dependencies (27)
+ 19 more |
|
5.1.0
unknown
|
5.1.0
unknown
Dependencies (27)
+ 19 more |
|
5.0.8
unknown
|
5.0.8
unknown
Dependencies (27)
+ 19 more |
|
5.0.5
unknown
|
5.0.5
unknown
Dependencies (27)
+ 19 more |
|
5.0.0
unknown
|
5.0.0
unknown
Dependencies (27)
+ 19 more |
|
4.2.1
unknown
|
4.2.1
unknown
Dependencies (27)
+ 19 more |
|
4.2.0
unknown
|
4.2.0
unknown
Dependencies (27)
+ 19 more |
|
4.1.7
unknown
|
4.1.7
unknown
Dependencies (27)
+ 19 more |
|
4.1.6
unknown
|
4.1.6
unknown
Dependencies (27)
+ 19 more |
|
4.1.4
unknown
|
4.1.4
unknown
Dependencies (27)
+ 19 more |
|
4.1.3
unknown
|
4.1.3
unknown
Dependencies (27)
+ 19 more |
|
4.1.2
unknown
|
4.1.2
unknown
Dependencies (28)
+ 20 more |
|
4.1.1
unknown
|
4.1.1
unknown
Dependencies (28)
+ 20 more |
|
4.1.0
unknown
|
4.1.0
unknown
Dependencies (28)
+ 20 more |
|
4.0.1
unknown
|
4.0.1
unknown
Dependencies (28)
+ 20 more |
|
4.0.0
unknown
|
4.0.0
unknown
Dependencies (28)
+ 20 more |
|
4.0.0-rc.11
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.11
unknown
Dependencies (28)
+ 20 more |
|
4.0.0-rc.10
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.10
unknown
Dependencies (28)
+ 20 more |
|
4.0.0-rc.9
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.9
unknown
Dependencies (28)
+ 20 more |
|
4.0.0-rc.8
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.8
unknown
Dependencies (28)
+ 20 more |
|
4.0.0-rc.7
unknown
yanked
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.7
unknown
yanked
Dependencies (28)
+ 20 more |
|
4.0.0-rc.6
unknown
yanked
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.6
unknown
yanked
Dependencies (28)
+ 20 more |
|
4.0.0-rc.5
unknown
yanked
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.5
unknown
yanked
Dependencies (28)
+ 20 more |
|
4.0.0-rc.4
unknown
yanked
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.4
unknown
yanked
Dependencies (28)
+ 20 more |
|
4.0.0-rc.3
unknown
yanked
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
4.0.0-rc.3
unknown
yanked
Dependencies (28)
+ 20 more |
|
3.4.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.4.0
unknown
Dependencies (29)
+ 21 more |
|
3.3.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.3.0
unknown
Dependencies (29)
+ 21 more |
|
3.2.1
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.2.1
unknown
Dependencies (29)
+ 21 more |
|
3.2.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.2.0
unknown
Dependencies (29)
+ 21 more |
|
3.1.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.1.0
unknown
Dependencies (29)
+ 21 more |
|
3.0.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.0.0
unknown
Dependencies (29)
+ 21 more |
|
3.0.0-rc4
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.0.0-rc4
unknown
Dependencies (29)
+ 21 more |
|
3.0.0-rc3
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.0.0-rc3
unknown
Dependencies (29)
+ 21 more |
|
3.0.0-rc1
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
3.0.0-rc1
unknown
Dependencies (25)
+ 17 more |
|
2.0.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
2.0.0
unknown
Dependencies (25)
+ 17 more |
|
1.2.0
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
1.2.0
unknown
Dependencies (24)
+ 16 more |
|
1.2.0-rc2
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
1.2.0-rc2
unknown
Dependencies (24)
+ 16 more |
|
1.2.0-rc1
unknown
1 CVE
GHSA-c873-wfhp-wx5m
Jan 15, 2025
SP1 has missing verifier checks and fiat-shamir observations
High
In SP1’s STARK verifier, the prover provided In the recursive verifier, every verifier program is generated beforehand and later checked for correctness by requiring a merkle proof to the precomputed merkle root of valid verifier keys. Therefore, the recursive verifier and the on-chain verifier were not affected by this vulnerability. This code was audited twice, once as a part of the audit by KALOS and once by Cantina for v1.0.0. This bug was found by the Succinct team during preparation of v4.0.0. Out of abundance of caution, we will be deprecating all previous versions and freeze the corresponding verifiers. Furthermore, in the recursive verifier, the This issue was found by a combined effort from Aligned, LambdaClass and 3MI Labs, and was also independently found by Succinct during the preparation of v4.0.0. Lastly, SP1’s STARK verifier relied on logic inside Plonky3, one SP1's core dependencies, to check that the polynomial evaluation claims are correct using a FRI-based polynomial commitment scheme. To batch this check, multiple polynomial evaluation claims are combined using a random linear combination. Prior to v4.0.0, the individual evaluation claims were not observed into the challenger before sampling the coefficient for the random linear combination. In v4.0.0, this was fixed by observing all the evaluation claims into the challenger correctly inside of Plonky3. This bug was found by Lev Soukhanov and Onur Kilic, and we have worked closely with the Plonky3 team to mitigate this vulnerability. We will be deprecating all previous versions and freezing their verifiers to ensure that versions with the vulnerability will not be used in production. Fixed in
4.0.0
References Updated Jan 28, 2025 · Source: OSV.dev |
1.2.0-rc1
unknown
Dependencies (23)
+ 15 more |