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?
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?
3. And should this target C first? Or a joint C/C++ proposal preferred?

I am happy to do the initial work on a paper if there is interest for
it.

Cheers,