Open github-actions[bot] opened 2 weeks ago
cosmwasm-crypto =2.0.4
is pulling curve25519-dalek ^3
via ed25519-zebra ^3
.
We need to wait until cosmwasm-crypto
releases a new version. main
branch already uses ed25519-zebra ^4.0.3
.
https://github.com/CosmWasm/cosmwasm/blob/main/packages/crypto/Cargo.toml#L22
curve25519-dalek
3.2.0
>=4.1.3
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
.The
Scalar29::sub
(32-bit) andScalar52::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: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
See advisory page for additional details.