CTTK: Constant-Time Toolkit

Their README did not say anything about what the project is but they have another document in the repo root that does. https://github.com/PLSysSec/FaCT/blob/rewrite/proposal.md

A part of constant-time coding is to avoid branches based on secret data, thus branch-free programming techniques apply. However, there is more to it; for instance, you must also avoid any memory access whose address depends on secret data (otherwise, the secret could leak through observation of the cache status).

On the other hand, branches that do not depend on secret data are OK in constant-time code. Typically, when you process a chunk of data, the chunk length is not secret, and there will be a loop whose exit condition really is a conditional jump that depends on the length.

branch-free is helpful but not a cure all. Any operation that takes a time variable on its input is subject to leaking information. Many X86 instructions appear to be constant time, but under certain conditions are not. So even when used in a branch-free style, information can still leak depending on the data and the instructions used.

This one is the opposite sort, in which code is carefully antioptimized to be as slow as the worst case (and optimized to make the worst case fast).

Everything else aside (where does one put the sleep?) probably stuff like https://www.sjoerdlangkemper.nl/2016/02/11/cracking-php-rand...

Even if your random() is cryptographically strong and not just an LCG, many samples over time will still be able to extract a signal.

That adds noise to the signal. The signal can still be recovered with more data, so while this helps, it’s not a complete solution.

Measuring the total runtime is only one of many kinds of timing attacks. The most effective timing attacks do not do that; instead, they measure time taken to access some specific memory areas _after_ the execution of the target code, in order to work out which cache lines were loaded by that code (this applies to both data and code caches, btw). These are "timing attacks" since they ultimately come from a measure of elapsed time, but not necessarily the time taken by the target code itself.

Also, when a thread is sleeping, the OS will schedule other threads, which opens many additional ways for attackers to notice that sleeping started.

Because this doesn't work at all, and would only help with one very specific kind of side channel (e.g. remote timing).

I've written about this before on this site: https://news.ycombinator.com/item?id=16069502

Doing that doesn't work, even for the timing oracle this it's meant to mitigate. There aren't one or two requests being made in timing attacks, and the sleep function only serves to slow down the valid calculations.

Suppose that x is the true time the operation takes. Then suppose that R is a random variable distributed uniformly on [0, 1000]. If I take a sample I will get values following the distribution x + R.

Then we calculate the sample mean of this distribution, X. Keep in mind that I can then set the number of samples to take to achieve my desired accuracy and confidence.

Then we look at the mean of the distribution x + R?

    E(x + R) = E(x) + E(R) = x + E(R) = x + 500

So therefore the true running time is recoverable by taking X - 500.

Constant Time refers to algorithms that execute in constant time without predictive branches on secret data. Constant Time is the accepted standard name for such.

It's fair to let cryptographers steal the "constant time" phrase. After all, buttcoiners stole "crypto" from them :)

O(1) is not constant time. It's bounded from above by a constant times 1 for sufficiently large values of N time.

In particular, sin(N) is O(1) despite never taking the same value twice.

It’s extremely standard terminology and only confusing if you haven’t been exposed to the concept timing attacks. (Which is great! Now you have.)

If the system being attacked does not limit attempts, one might repeat their requests until they achieve statistical significance. The first Stripe CTF had a level that dealt with timing attacks, and that is the approach I took.

Except for the fact that virtually all modern serverside applications live on shared hardware with anonymous cotenants, and all modern clientside applications are JIT'd from random websites, but sure.

I'm not sure why you believe that, since your belief runs contrary to the real-world oracular attacks against .Net and Ruby on Rails. Also, see Lucky-13, POODLE, and Logjam.

You should read "Remote Timing Attacks are Practical" (https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf) published in 2003 by David Brumley and Dan Boneh.