`const fn` support

[tarcieri]

In crypto-bigint we've had to build an entirely parallel set of types in order to support const fn: ConstChoice and ConstCtOption, which are const fn-friendly versions of subtle's equivalent Choice and CtOption.

It would be nice to have upstream support for this in subtle some way.

[rubdos]

We have the following code in a fork:

/// Create a [Choice] in const context.
#[cfg(feature = "core_hint_black_box")]
#[inline]
pub const fn from_u8_const(input: u8) -> Self {
    debug_assert!((input == 0u8) | (input == 1u8));

    Choice(core::hint::black_box(input))
}

black_box, however, is a no-op in const context. The safety of Choice is at time of creation, not on evaluation, but I do wonder whether this is even relevant in any situation? If you have a Choice(1u8), the compiler may make assumptions based on that knowledge, but these assumptions are compile-time assumptions anyway so it might not even matter.

[tarcieri]

FWIW I've partially built a subtle-like library that directly embraces const fn and always uses black_box in a belt-and-suspenders capacity where there is at least one additional mitigation to rely on so we don't have to worry if it's replaced with an identity function.

It's also built on the cmov for predication when doing selections.

Regarding some of your questions, yes doing a black_box at construction time seems insufficient to me, looking at e.g. RUSTSEC-2024-0344 it should be instead on every access to the Choice, to prevent the compiler from optimizing over a particular value for multiple successive accesses.

I'm working on a number of other things for @RustCrypto but I hope to publish my crate soon. And perhaps it can inform a series of changes that could eventually become subtle 3.0. There are a number of issues with subtle in its current form which require breaking changes.

[tarcieri]

I pushed up my woefully completed WIP here: RustCrypto/utils#1243

Note that I described it as an experimental library that could help inform a potential subtle v3.