GHSA-X4GP-PQPJ-F43Q
Vulnerability from github – Published: 2024-06-18 21:56 – Updated: 2025-07-28 15:46Timing 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 curve25519-dalek.
The Scalar29::sub (32-bit) and Scalar52::sub (64-bit) functions contained usage of a mask value inside a loop where LLVM saw an opportunity to insert a branch instruction (jns on x86) to conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:
- 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv
- 64-bit (see L48): https://godbolt.org/z/PczYj7Pda
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:
- 32-bit: https://godbolt.org/z/jc9j7eb8E
- 64-bit: https://godbolt.org/z/x8d46Yfah
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
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "curve25519-dalek"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "4.1.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2024-58262"
],
"database_specific": {
"cwe_ids": [
"CWE-203"
],
"github_reviewed": true,
"github_reviewed_at": "2024-06-18T21:56:24Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "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 `curve25519-dalek`.\n\nThe `Scalar29::sub` (32-bit) and `Scalar52::sub` (64-bit) functions contained usage of a mask value inside a loop where LLVM saw an opportunity to insert a branch instruction (`jns` on x86) to conditionally bypass this code section when the mask value is set to zero as can be seen in godbolt:\n\n- 32-bit (see L106): https://godbolt.org/z/zvaWxzvqv\n- 64-bit (see L48): https://godbolt.org/z/PczYj7Pda\n\nA similar problem was recently discovered in the Kyber reference implementation:\n\nhttps://groups.google.com/a/list.nist.gov/g/pqc-forum/c/hqbtIGFKIpU/m/cnE3pbueBgAJ\n\nAs 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.\n\nThe fix can be validated in godbolt here:\n\n- 32-bit: https://godbolt.org/z/jc9j7eb8E\n- 64-bit: https://godbolt.org/z/x8d46Yfah\n\nThe problem was discovered and the solution independently verified by Alexander Wagner \u003calexander.wagner@aisec.fraunhofer.de\u003e and Lea Themint \u003clea.thiemt@tum.de\u003e using their DATA tool:\n\nhttps://github.com/Fraunhofer-AISEC/DATA",
"id": "GHSA-x4gp-pqpj-f43q",
"modified": "2025-07-28T15:46:43Z",
"published": "2024-06-18T21:56:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58262"
},
{
"type": "WEB",
"url": "https://github.com/dalek-cryptography/curve25519-dalek/pull/659"
},
{
"type": "WEB",
"url": "https://github.com/dalek-cryptography/curve25519-dalek/commit/415892acf1cdf9161bd6a4c99bc2f4cb8fae5e6a"
},
{
"type": "PACKAGE",
"url": "https://github.com/dalek-cryptography/curve25519-dalek"
},
{
"type": "WEB",
"url": "https://rustsec.org/advisories/RUSTSEC-2024-0344.html"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "curve25519-dalek has timing variability in `curve25519-dalek`\u0027s `Scalar29::sub`/`Scalar52::sub`"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.