SECURITY: fix timing variability in backend/serial/u64/scalar.rs #659

rozbb · 2024-06-18T17:09:17Z

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 Scalar52::sub function contained usage of a mask value inside of 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:

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:

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

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 `Scalar52::sub` function contained usage of a mask value inside of 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: 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: 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

Similar security fix to #659, but for the 32-bit backend. See that PR for more information about the problem.

@tarcieri

Similar security fix to #659, but for the 32-bit backend. See that PR for more information about the problem. Relevant compiler outputs (thanks to @tarcieri): Without fix https://godbolt.org/z/zvaWxzvqv Notice the `jns` ("jump if not sign") instruction on line 106. With fix https://godbolt.org/z/jc9j7eb8E

## Description Fixes `cargo-deny` warning for [RUSTSEC-2024-0344](https://rustsec.org/advisories/RUSTSEC-2024-0344): *Timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`* Upstream PR: dalek-cryptography/curve25519-dalek#659 ## Breaking Changes  ## Notes & open questions  ## Change checklist - [x] Self-review. - [ ] ~~Documentation updates if relevant.~~ - [ ] ~~Tests if relevant.~~ - [x] All breaking changes documented.

For the issue in the reference implementation, see pq-crystals/kyber@9b8d306 And for the method of fixing, see dalek-cryptography/curve25519-dalek#659

Resolve security issue dalek-cryptography/curve25519-dalek#659.

## [0.6.1] - 2024-06-20 This is a bug fixing and security release. curve255190-dalek has been upgraded to v4.1.3, see [dalek-cryptography/curve25519-dalek#659](dalek-cryptography/curve25519-dalek#659) for details. ### Fixed - kad: Set default ttl 36h for kad records ([#154](#154)) - chore: update ed25519-dalek to v2.1.1 ([#122](#122)) - Bump curve255190-dalek 4.1.2 -> 4.1.3 ([#159](#159))

Replaces the security mitigation added in #659 and #661 for masking-related timing variability which used an inline `black_box` using the recently added `subtle::BlackBox` newtype (see dalek-cryptography/subtle#123) Internally `BlackBox` uses a volatile read by default (i.e. same strategy which was used before) or when the `core_hint_black_box` feature of `subtle` is enabled, it uses `core::hint::black_box` (whose documentation was recently updated to reflect the nuances of potential cryptographic use, see rust-lang/rust#126703) This PR goes ahead and uses `BlackBox` for both `mask` and `underflow_mask` where previously it was only used on `underflow_mask`. The general pattern of bitwise masking inside a loop seems worrisome for the optimizer potentially inserting branches in the future. Below are godbolt inspections of the generated assembly, which are free of the `jns` instructions originally spotted in #659/#661: - 32-bit (read_volatile): https://godbolt.org/z/TKo9fqza4 - 32-bit (hint::black_box): https://godbolt.org/z/caoMxYbET - 64-bit (read_volatile): https://godbolt.org/z/PM6zKjj1f - 64-bit (hint::black_box): https://godbolt.org/z/nseaPvdWv

## Description Fixes `cargo-deny` warning for [RUSTSEC-2024-0344](https://rustsec.org/advisories/RUSTSEC-2024-0344): *Timing variability in `curve25519-dalek`'s `Scalar29::sub`/`Scalar52::sub`* Upstream PR: dalek-cryptography/curve25519-dalek#659 ## Breaking Changes  ## Notes & open questions  ## Change checklist - [x] Self-review. - [ ] ~~Documentation updates if relevant.~~ - [ ] ~~Tests if relevant.~~ - [x] All breaking changes documented.

Replaces the security mitigation added in #659 and #661 for masking-related timing variability which used an inline `black_box` using the recently added `subtle::BlackBox` newtype (see dalek-cryptography/subtle#123) Internally `BlackBox` uses a volatile read by default (i.e. same strategy which was used before) or when the `core_hint_black_box` feature of `subtle` is enabled, it uses `core::hint::black_box` (whose documentation was recently updated to reflect the nuances of potential cryptographic use, see rust-lang/rust#126703) This PR goes ahead and uses `BlackBox` for both `mask` and `underflow_mask` where previously it was only used on `underflow_mask`. The general pattern of bitwise masking inside a loop seems worrisome for the optimizer potentially inserting branches in the future. Below are godbolt inspections of the generated assembly, which are free of the `jns` instructions originally spotted in #659/#661: - 32-bit (read_volatile): https://godbolt.org/z/TKo9fqza4 - 32-bit (hint::black_box): https://godbolt.org/z/caoMxYbET - 64-bit (read_volatile): https://godbolt.org/z/PM6zKjj1f - 64-bit (hint::black_box): https://godbolt.org/z/nseaPvdWv

Alternative to #659/#661 and #662 which leverages `subtle::Choice` and `subtle::ConditionallySelectable` as the optimization barriers. Really the previous masking was there to conditionally add the scalar field modulus on underflow, so instead of that, we can conditionally select zero or the modulus using a `Choice` constructed from the underflow bit.

…ek-cryptography#659) 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 `Scalar52::sub` function contained usage of a mask value inside of 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: 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: 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 Co-authored-by: Tony Arcieri <bascule@gmail.com>

@tarcieri

…ek-cryptography#661) Similar security fix to dalek-cryptography#659, but for the 32-bit backend. See that PR for more information about the problem. Relevant compiler outputs (thanks to @tarcieri): Without fix https://godbolt.org/z/zvaWxzvqv Notice the `jns` ("jump if not sign") instruction on line 106. With fix https://godbolt.org/z/jc9j7eb8E

…y#662) Replaces the security mitigation added in dalek-cryptography#659 and dalek-cryptography#661 for masking-related timing variability which used an inline `black_box` using the recently added `subtle::BlackBox` newtype (see dalek-cryptography/subtle#123) Internally `BlackBox` uses a volatile read by default (i.e. same strategy which was used before) or when the `core_hint_black_box` feature of `subtle` is enabled, it uses `core::hint::black_box` (whose documentation was recently updated to reflect the nuances of potential cryptographic use, see rust-lang/rust#126703) This PR goes ahead and uses `BlackBox` for both `mask` and `underflow_mask` where previously it was only used on `underflow_mask`. The general pattern of bitwise masking inside a loop seems worrisome for the optimizer potentially inserting branches in the future. Below are godbolt inspections of the generated assembly, which are free of the `jns` instructions originally spotted in dalek-cryptography#659/dalek-cryptography#661: - 32-bit (read_volatile): https://godbolt.org/z/TKo9fqza4 - 32-bit (hint::black_box): https://godbolt.org/z/caoMxYbET - 64-bit (read_volatile): https://godbolt.org/z/PM6zKjj1f - 64-bit (hint::black_box): https://godbolt.org/z/nseaPvdWv

@tarcieri

…ek-cryptography#661) Similar security fix to dalek-cryptography#659, but for the 32-bit backend. See that PR for more information about the problem. Relevant compiler outputs (thanks to @tarcieri): Without fix https://godbolt.org/z/zvaWxzvqv Notice the `jns` ("jump if not sign") instruction on line 106. With fix https://godbolt.org/z/jc9j7eb8E

…ek-cryptography#659) 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 `Scalar52::sub` function contained usage of a mask value inside of 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: 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: 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 Co-authored-by: Tony Arcieri <bascule@gmail.com>

@tarcieri

…ek-cryptography#661) Similar security fix to dalek-cryptography#659, but for the 32-bit backend. See that PR for more information about the problem. Relevant compiler outputs (thanks to @tarcieri): Without fix https://godbolt.org/z/zvaWxzvqv Notice the `jns` ("jump if not sign") instruction on line 106. With fix https://godbolt.org/z/jc9j7eb8E

…ek-cryptography#659) 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 `Scalar52::sub` function contained usage of a mask value inside of 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: 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: 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 Co-authored-by: Tony Arcieri <bascule@gmail.com>

rozbb requested a review from tarcieri June 18, 2024 17:09

tarcieri approved these changes Jun 18, 2024

View reviewed changes

tarcieri added bug safety - constant timedness labels Jun 18, 2024

rozbb merged commit 415892a into main Jun 18, 2024
44 checks passed

tarcieri deleted the fix branch June 18, 2024 17:50

tarcieri added a commit that referenced this pull request Jun 18, 2024

SECURITY: fix timing variability in backend/serial/u32/scalar.rs

4e6a2cf

Similar security fix to #659, but for the 32-bit backend. See that PR for more information about the problem.

tarcieri mentioned this pull request Jun 18, 2024

SECURITY: fix timing variability in backend/serial/u32/scalar.rs #661

Merged

tarcieri added a commit that referenced this pull request Jun 18, 2024

SECURITY: fix timing variability in backend/serial/u32/scalar.rs

dac6f1b

Similar security fix to #659, but for the 32-bit backend. See that PR for more information about the problem.

Frando mentioned this pull request Jun 18, 2024

deps: bump curve25519-dalek n0-computer/iroh#2382

Merged

4 tasks

nazar-pc mentioned this pull request Jun 19, 2024

Upgrade libp2p to 0.52.4 paritytech/polkadot-sdk#1631

Merged

7 tasks

AlexD10S mentioned this pull request Jun 20, 2024

Vulnerability dependency r0gue-io/pop-cli#214

Open

dmitry-markin mentioned this pull request Jun 20, 2024

Bump curve255190-dalek 4.1.2 -> 4.1.3 paritytech/litep2p#159

Merged

dmitry-markin added a commit to paritytech/litep2p that referenced this pull request Jun 20, 2024

Bump curve255190-dalek 4.1.2 -> 4.1.3 (#159)

c57dbc6

Resolve security issue dalek-cryptography/curve25519-dalek#659.

dmitry-markin mentioned this pull request Jun 20, 2024

chore: Release v0.6.1 paritytech/litep2p#160

Merged

tarcieri mentioned this pull request Jun 20, 2024

ml-kem: potential timing vside channel converting message to polynomial RustCrypto/KEMs#32

Closed

tarcieri mentioned this pull request Jun 20, 2024

curve: use subtle::BlackBox optimization barrier #662

Merged

tarcieri mentioned this pull request Jun 25, 2024

curve: use subtle::Choice for constant-time fixes #665

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SECURITY: fix timing variability in backend/serial/u64/scalar.rs #659

SECURITY: fix timing variability in backend/serial/u64/scalar.rs #659

rozbb commented Jun 18, 2024

SECURITY: fix timing variability in backend/serial/u64/scalar.rs #659

SECURITY: fix timing variability in backend/serial/u64/scalar.rs #659

Conversation

rozbb commented Jun 18, 2024