It is encouraging to see BearSSL at beta stage. I believe the last time I saw it, Thomas still considered it to be alpha. The promise of a small, MIT-licensed crypto library, written by a solid cryptographer who understands implementation details is nice. I’ve used libtomcrypt in the past, but as a non-expert, I’ve always wondered how resilient and well-written the code base is.
I got no idea what to expect now, but I've never seen it used in anything I'd consider serious. To many people, it's forever tainted. The lack of CVE in libtomcrypt is not an indication of quality, just and indication of lack of usage. In any case, its lack of support for PKCS#11 means it's not suitable for use cases where keys must be securely stored.
It's worth noting that no validation is strictly necessary, but some iinputs can force the output to be all-0. That should be checked.
 RFC 7748 (https://www.ietf.org/rfc/rfc7748.txt), p. 14
Other implementations purely in hardware or purely in software would be constant-time, but the x86, only offering an instruction for the conversion to signed integer, leads to a mixed solution in which the short sequence of instructions generated by compilers contains a conditional branch on the value being converted.
Why not do this for crypto?
You can then emit an object file containing the functions you're interested in and link it to the rest of your non-constant-time program.
This has more potential just because it could be licensed in embedded sector to reduce work on things such as WCET analysis for hard-real-time. That money and uptake can feed back into the compiler's development for things such as constant-time-preserving optimizations. I haven't seen one of these, though. They typically do timing analysis manually (i.e. specific tool) since they have to assess the algorithms themselves, interactions with other components, and so on. Neatest thing I found looking into that was a formally-verified WCET analyses that was built on top of CompCert compiler.
Oh wait, just found something:
How would the compiler knows if the code it's given is constant-time ? It's actually a property quite hard to verify due to pointer aliasing or whatnot.
Another angle is to have a compiler that always outputs constant-time code. It's always possible, at least for crypto code according to Peter Schwabe, just that it's probably not going to be very fast code...
Because an arbitrary C program will have non-constant branches (so may become exponentially long in your proposed instruction set) and loops (not representable at all in your proposed instruction set)?
If what you are saying is that a language could hypothetically statically verify that the execution of a function was constant time with respect to certain inputs, that sounds like it would work and that the only obstacle is engineering effort. But compiling to such a language doesn't sound very practical to me.
All I remember at the time was thinking I had no idea why anyone would want this. But then someone (on either hn or proggit) mentioned that there were crypto reasons why it would be useful.
So I suspect that compiling isn't too bad ... however, programming with it probably is annoying.
EDIT: Actually, it looks like it was top comment in this thread: https://news.ycombinator.com/item?id=7557089
Kind of a neat idea at any rate.
But more importantly, that only covers the basic timing attack side channel and not even that very well. Cache and branch predictor attacks are still possible (and these are a bigger threat when you're using a virtual machine that may be shared with your adversary). Not to mention all the side channels (power consumption, etc) that are visible if your hardware is compromised.
And if you do end up yielding a thread, the context switch overhead will be measurable. It can take hundreds of microseconds to fully recover from a context switch (TLBs and cache misses, etc), which will certainly affect the timing. It would almost certainly be possible to detect if the encryption method yielded the thread or not based on timing alone (e.g. encrypting next block would consume more time after a thread yield).
There are no easy ways out, crypto code should be free of side channels: constant time, no data dependent memory accesses (cache attack), no data dependent branches (branch predictor attack), etc. This requires the crypto implementor not only to be proficient in the mathematics of cryptography but also details of the computer architecture they're running on.
This kind of leak still counts as a "timing attack" because the test for cache eviction is based on the time it takes to next access the relevant element (and this occurs _after_ the cryptographic computation, from other code). Notably, this can still be done remotely, possibly from a large distance, thanks to the efficiency of modern networking (this is what makes timing attacks special among side-channel leaks: power analysis, electro-magnetic emissions, sound... require the attacker to be in the physical vicinity of the target system, while timing attacks may be performed from hundreds of miles away). Demonstrations have been made with network access (over ethernet or optic fibre), and, in another kind of setup, when the attacker can run his own code on the same hardware, even with logical isolation (another process, or even in another VM that happens to run on some other cores of the same machine).
Thus, "true" constant-time code will make no memory access at an address that depends on secret data (but the data contents, of course, may be secret). Similarly, it won't make conditional jumps that depend on secret data (because of the cache accesses for loading the code, and also because of the jump prediction cache, both having been successfully exploited in lab demonstrations).
But you get much more, because if one analyzes physical conditions (cpu/memory usage, temperature, time itself), he can't gather information about the secrets.