Repository navigation
Conversation
tarcieri
commented
Oct 28, 2025
tarcieri
commented
Oct 28, 2025
tarcieri
commented
Oct 28, 2025
tarcieri
commented
Oct 28, 2025
|
So why not just bump the MSRV to 1.86? |
Member
Author
|
@fjarri we're trying to ship everything as 1.85 so it can be packaged on Debian stable, then bumping MSRV after that (now that there's an MSRV-aware resolver) That said, there are several places post-1.85 features would be nice in |
tarcieri
force-pushed
the
ctutils
branch
8 times, most recently
from
December 20, 2025 00:26
ab9d02c to
9511556
Compare
Member
Author
|
Ugh, |
Inspired by the `subtle` crate, this is a next-generation constant time utility crate built on the `cmov` crate's constant-time selection/predication and equality comparisons, which are exposed as `CtSelect` and `CtEq` traits (equivalent to `ConditionallySelectable` and `ConstantTimeEq` in `subtle`). Additionally, it uses `black_box` as a "best effort" optimization barrier whenever accessing its constant time conditional type (called `Choice` as in `subtle`), providing an additional line of defense against possible future compiler optimizations. It also has a `CtOption` type like `subtle` which provides a constant-time equivalent to `Option` but with combinators that are evaluated eagerly rather than lazily so they behave the same regardless of the effective absence or presence of the underlying value. It proactively makes functions `const fn` wherever possible, making it possible to construct and use `Choice` and `CtOption` in these contexts. The `Copy` bounds have been removed, making it possible for everything to be used on heap-allocated types, such as `BoxedUint` in `crypto-bigint`. The above two issues taken together are the main reasons why `crypto-bigint` currently embeds its own mini-`subtle` alike, which it would be nice to use this library to replace.
tarcieri
marked this pull request as ready for review
December 20, 2025 00:41
Member
Author
|
I'd like to finally push this one past the draft PR it's been sitting in for ages and land it and iterate on new features/functionality. I'm going to go ahead and merge but I'd appreciate any retroactive review. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
(for lack of a better name)
This is woefully incomplete but I'm pushing it up anyway since several people have asked aboutconst fnsupport forsubtleThis is effectively a rewrite of
subtleusing thecmovcrate for both constant-time selection/predication as well as equality comparisons. Thecmovcrate uses architecture-specific predication instructions on x86(_64) and ARM, with a portable "best effort" fallback.It uses
core::hint::black_boxon-access as an optimization barrier, however this is a belt-and-suspenders defense paired with the use of intrinsics where available. This is a bit different thansubtlewhich uses a similar black box optimization barrier at initialization time. There are a couple problems with this approach:Choice, which means it could potentially insert a branch to e.g. shortcut-on-zeroblack_boxis (rather annoyingly) onlyconst fnin Rust 1.86.This is targeting an initial MSRV of 1.85This PR is MSRV 1.87 but we'll have a revertable downgrade to 1.85, as well as supportingconst fnconstructors forChoicewhich are a big missing piece insubtleright nowI'm not intending to replace our usages of
subtlewith this yet (I'd much rather ship everything), but would like to have a testbed for usingcmovfor constant-time operations which can perhaps inform a potentialsubtlev3.0 (if I can make that happen).To be useful, this still needs an equivalent ofAdded!CtOption(ideally with much moreconst fnsupport), which I was hoping to implement before pushing this up.One thing we could consider is trying to get this complete enough to use in
crypto-bigintto replaceConstChoice/ConstCtOption, though it would likely need all of the methods onChoiceto beconst fn, which would probably involve shippingChoicewithoutblack_box(i.e. whatcrypto-bigintis already doing), and then adding asubtleintegration for convertingctutil::Choice->subtle::Choiceand a prospectivectutil::CtOption->subtle::CtOption.cc @andrewwhitehead @fjarri @ycscaly