curve25519-dalek
Activity
- Latest release
- 2mo ago
- Total releases
- 104
- Cadence
- ~20 days
- Last 12 months
- 8
Details
- License
- BSD-3-Clause
- First release
- Dec 08, 2016
| Version | Released | |
|---|---|---|
5.0.0
unknown
|
5.0.0
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-rc.1
unknown
|
5.0.0-rc.1
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-rc.0
unknown
|
5.0.0-rc.0
unknown
Dependencies (16)
+ 8 more |
|
5.0.0-pre.6
unknown
|
5.0.0-pre.6
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-pre.5
unknown
|
5.0.0-pre.5
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-pre.4
unknown
|
5.0.0-pre.4
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-pre.3
unknown
|
5.0.0-pre.3
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-pre.2
unknown
|
5.0.0-pre.2
unknown
Dependencies (18)
+ 10 more |
|
5.0.0-pre.1
unknown
|
5.0.0-pre.1
unknown
Dependencies (19)
+ 11 more |
|
5.0.0-pre.0
unknown
|
5.0.0-pre.0
unknown
Dependencies (18)
+ 10 more |
|
4.2.0
unknown
yanked
|
4.2.0
unknown
yanked
Dependencies (18)
+ 10 more |
|
4.1.3
unknown
|
4.1.3
unknown
Dependencies (18)
+ 10 more |
|
4.1.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.1.2
unknown
Dependencies (19)
+ 11 more |
|
4.1.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.1.1
unknown
Dependencies (19)
+ 11 more |
|
4.1.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.1.0
unknown
Dependencies (18)
+ 10 more |
|
4.0.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0
unknown
Dependencies (17)
+ 9 more |
|
4.0.0-rc.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-rc.3
unknown
Dependencies (17)
+ 9 more |
|
4.0.0-rc.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-rc.2
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-rc.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-rc.1
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-rc.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-rc.0
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-pre.5
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.5
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-pre.4
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.4
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-pre.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.3
unknown
Dependencies (15)
+ 7 more |
|
4.0.0-pre.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.2
unknown
Dependencies (13)
+ 5 more |
|
3.2.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.2.1
unknown
Dependencies (13)
+ 5 more |
|
3.1.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.1.3
unknown
Dependencies (13)
+ 5 more |
|
4.0.0-pre.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.1
unknown
Dependencies (13)
+ 5 more |
|
3.2.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.2.0
unknown
Dependencies (13)
+ 5 more |
|
3.1.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.1.2
unknown
Dependencies (13)
+ 5 more |
|
3.1.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.1.1
unknown
Dependencies (13)
+ 5 more |
|
3.0.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.0.3
unknown
Dependencies (11)
+ 3 more |
|
2.1.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.1.3
unknown
Dependencies (11)
+ 3 more |
|
4.0.0-pre.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
4.0.0-pre.0
unknown
Dependencies (13)
+ 5 more |
|
3.1.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.1.0
unknown
Dependencies (13)
+ 5 more |
|
3.0.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.0.2
unknown
Dependencies (11)
+ 3 more |
|
2.1.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.1.2
unknown
Dependencies (11)
+ 3 more |
|
1.2.6
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.6
unknown
Dependencies (19)
+ 11 more |
|
1.2.5
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.5
unknown
Dependencies (19)
+ 11 more |
|
2.1.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.1.1
unknown
Dependencies (11)
+ 3 more |
|
3.0.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.0.1
unknown
Dependencies (11)
+ 3 more |
|
3.0.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
3.0.0
unknown
Dependencies (11)
+ 3 more |
|
1.2.4
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.4
unknown
Dependencies (19)
+ 11 more |
|
2.1.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.1.0
unknown
Dependencies (11)
+ 3 more |
|
2.0.0
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.0.0
unknown
Dependencies (11)
+ 3 more |
|
2.0.0-alpha.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.0.0-alpha.2
unknown
Dependencies (11)
+ 3 more |
|
2.0.0-alpha.1
unknown
yanked
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.0.0-alpha.1
unknown
yanked
Dependencies (12)
+ 4 more |
|
2.0.0-alpha.0
unknown
yanked
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
2.0.0-alpha.0
unknown
yanked
Dependencies (12)
+ 4 more |
|
1.2.3
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.3
unknown
Dependencies (19)
+ 11 more |
|
1.2.2
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.2
unknown
Dependencies (19)
+ 11 more |
|
1.2.1
unknown
1 CVE
CVE-2024-58262
GHSA-x4gp-pqpj-f43q
RUSTSEC-2024-0344
Jun 18, 2024
curve25519-dalek has timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`
2.9
/ 10
Low
Local
High
None
None
Unchanged
Low
None
None
Timing variability of any kind is problematic when working with potentially secret values such as elliptic curve scalars, and such issues can potentially leak private keys and other secrets. Such a problem was recently discovered in The
A similar problem was recently discovered in the Kyber reference implementation: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ As discussed on that thread, one portable solution, which is also used in this PR, is to introduce a volatile read as an optimization barrier, which prevents the compiler from optimizing it away. The fix can be validated in godbolt here:
The problem was discovered and the solution independently verified by Alexander Wagner alexander.wagner@aisec.fraunhofer.de and Lea Themint lea.thiemt@tum.de using their DATA tool: https://github.com/Fraunhofer-AISEC/DATA Fixed in
4.1.3
References
Updated Sep 10, 2026 · Source: OSV.dev |
1.2.1
unknown
Dependencies (19)
+ 11 more |