On 2025-12-09 14:26, Jonathan Wakely wrote:
> On Tue, 9 Dec 2025, 08:08 Shivam Kunwar via Std-Proposals,
> <std-proposals_at_[hidden]> wrote:
>
>> Hi all,
>>
>> I'd like to float an idea for a potential future proposal and gauge
>> interest before investing time in a formal paper.
>>
>> The Problem :
>>
>> Cryptographic code needs to perform conditional selection without
>> leaking timing information. The standard pattern looks like this
>>
>> // Intended to be constant-time
>> uint64_t mask = -(uint64_t)(!!cond);
>> result = (a & mask) | (b & ~mask);
>>
>> Unfortunately, modern compilers sees this as an opportunity to
>> optimize
>> and transform it back into branches or conditional memory access.
>>
>> The precedent :
>>
>> C23's `memset_explicit` solved an analogous problem: compilers
>> eliminating "dead" stores to sensitive data. The solution was
>> elegant,
>> rather than trying to formally define "don't optimize" in the
>> abstract
>> machine, the standard simply states the intent.
>>
>> "The purpose of this function is to make sensitive information
>> stored in
>> the object inaccessible."
>>
>> And implementors understand what this means without requiring the
>> changes to the abstract machine model.
>>
>> The Idea :
>>
>> Apply the similar approach to constant-time selection:
>>
>> // C
>> uintmax_t select_explicit(int test, uintmax_t a, uintmax_t b);
>>
>> // C++ (possibly in a std::ct namespace)
>> template<class T>
>> constexpr T select_explicit(bool test, T a, T b) noexcept;
>>
>> which basically means
>>
>> "Returns a if test is true, otherwise b. The selection shall be
>> performed in a manner that does not reveal information about test
>> through timing side-channels."
>>
>> Trail of Bits has an RFC under review for LLVM 22 introducing
>> __builtin_ct_select:
>> https://discourse.llvm.org/t/rfc-constant-time-coding-support/87781
>> The thread has good engagement from the crypto community and LLVM
>> developers. OpenSSL, libsodium, and BearSSL all have their own
>> internal
>> constant time selection implementations that could benefit from
>> standardization.
>>
>> Few engagement questions :
>>
>> 1. Is there existing work in this direction?
>
> Not that I am aware of.
>
>> 2. Would this be better as a library only proposal (like
>> memset_explicit), or does the committee see value in a broader
>> "secret
>> types" approach as discussed in the LLVM thread?
>
> I would start with the library function, to limit the scope. A larger,
> more adventurous proposal is likely to be difficult.
>
> On the other hand, is a select operation sufficient or is it just one
> of many similar operations that are needed to be practically useful?
>
>> 3. And should this target C first? Or a joint C/C++ proposal
>> preferred?
>
> Aren't most of the SSL libraries written in C, so wouldn't even
> benefit from something that's only in C++?
>
>> I am happy to do the initial work on a paper if there is interest
>> for
>> it.
>
>>

Thanks Jonathan for the reply!

Agreed that memset_explicit path seems much more tracable than trying to
introduce secret types into the type system.

And good question about the similar operations that are needed, so the
most critical one at the moment is

Selection (select_explicit)
Comparison (compare_explicit)
Conditional swap (which used heavily in elliptic curve code)

and beyond that, there are many nice to haves like constant-time
min/max, shifts with secret distances, arithmetic operations, etc.

I would like to start with just `select_explicit` and
`compare_explicit`.

Thanks again for your feedback!