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.
>