
CTTK: Constant-Time Toolkit - matt_d
https://github.com/pornin/CTTK
======
fenollp
If that interests you you should take a look at
[https://github.com/PLSysSec/FaCT](https://github.com/PLSysSec/FaCT)

~~~
bringtheaction
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](https://github.com/PLSysSec/FaCT/blob/rewrite/proposal.md)

~~~
ozzmotik
oh hey thanks for pointing that out, I was noticing that there wasn't much
detail about the project in the Readme. ++ to you for finding that

------
kccqzy
How does this compare with typical branch-free programming? The kind that’s so
latency-sensitive that we don’t even trust the branch predictor and don’t want
to pay for mispredictions?

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

~~~
blattimwind
One somewhat ugly truth is, that you _can 't_ implement some algorithms
securely in software while retaining good or even acceptable performance. As
we've seen previously, performance is critical for crypto, because people
_will_ choose something faster over the proper, secure alternative, especially
if the insecurity is _not_ an obvious or hard failure, as it is with side
channels.

The modern approach to this issue is to design algorithms _specifically_ for
software implementation and avoid entire classes of side channels already in
the design of the algorithm. This is one of the noticeable differences between
older primitives (NIST/SECG ECC, DSA, RSA, a whole bunch of ciphers) and newer
primitives designed for software (EdDSA over sensible curves, X25519, Chacha20
and so on).

------
zaarn
I wonder if it would be viable to abuse the movfuscator to achieve similar
effects. Since all code in the movfuscator runs in a loop without branches, it
would be effectively constant time too...

------
hacker_9
Why not just append `thread.sleep(random() % 1000)' to your calculations if
you are worried about timing attacks?

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

~~~
brilee
I'm not sure how that article applies; it discusses the hazards of using a
PRNG. I think the actual objection is that it just increases the number of
samples required, but doesn't fix the problem.

------
friendlydude12
Calling this “Constant time” is a bit confusing. I thought it was going to be
a library of algorithms for solving O(1) problems. “Timing attack resistant”
would be a better name.

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

~~~
friendlydude12
Thanks, I went to college too and was fully aware of the formal definition of
O() notation. That doesn’t change the fact that colloquially it’s far more
common to use the phrase “constant time” when referring to time complexity
rather than timing attack resistance.

~~~
pinko
Colin did a little more than "go to college".

~~~
friendlydude12
Oh really? Please explain to me how that is relevant to the point being made
in this thread.
[https://en.wikipedia.org/wiki/Time_complexity#Constant_time](https://en.wikipedia.org/wiki/Time_complexity#Constant_time)

------
platz
I think the ability to actually exploit timing attacks is bit over indexed.
Almost all of the time you need direct access on the machine, i.e. not a
webserver. So it's more of a concern for native environments as opposed to
networked environments.

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

