News for hackers. Stuff that matters.
Re:CTTK: Constant-Time Toolkit by hacker_9 on Sunday February 25, 2018 @01:01PM (#16460202)
Why not just append `thread.sleep(random() % 1000)' to your calculations if you are worried about timing attacks?
Re:CTTK: Constant-Time Toolkit by Spivak on Sunday February 25, 2018 @01:49PM (#16460442)
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.
Re:CTTK: Constant-Time Toolkit by pornin on Sunday February 25, 2018 @01:19PM (#16460294)
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.

Re:CTTK: Constant-Time Toolkit by blattimwind on Sunday February 25, 2018 @01:20PM (#16460301)
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

Re:CTTK: Constant-Time Toolkit by mikeash on Sunday February 25, 2018 @01:11PM (#16460259)
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.
Re:CTTK: Constant-Time Toolkit by IncRnd on Sunday February 25, 2018 @01:33PM (#16460361)
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.
Re:CTTK: Constant-Time Toolkit by barrkel on Sunday February 25, 2018 @01:11PM (#16460256)
Even if your random() is cryptographically strong and not just an LCG, many samples over time will still be able to extract a signal.
Re:CTTK: Constant-Time Toolkit by a_t48 on Sunday February 25, 2018 @01:04PM (#16460225)
Everything else aside (where does one put the sleep?) probably stuff like https://www.sjoerdlangkemper.nl/2016/02/11/cracking-php-rand...
Re:CTTK: Constant-Time Toolkit by brilee on Sunday February 25, 2018 @01:15PM (#16460274)
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.