Security of OpenSSL ECDSA signatures

[Dan Kaminsky]

>
> random delays will not help because you can sample to eliminate them. I
> think you would want something like the following, that rounds signing
> operations up to the next power of two milliseconds.
>
>
I could see some weird corner case where the private key determines which
edge a delay falls on, causing a response in 2ms or 4ms.  That's actually a
really clean signal to look for.

The gold standard is constant time.  But making every operation constant
time is hard, and getting harder, due to higher level languages (not our
problem).  In theory, a random delay can be teased out by looking at the
peak of the distribution of results -- it'll be slightly shifted when the
original delay is minimal rather than maximal.

But I tell you, I sure note the people doing timing attacks at the tens of
nanosecond scale aren't getting their attacks to work versus Internet level
latencies...that something is possible after billions of packets does not
mean that something is necessarily practical.

So I'd definitely do random noise over next-power-of-two-ms.

Better than both though would be to discover the worst case scenario time
for a handful of keys, double that, and then sleep until twice the
difference has elapsed.  So, if the worst case scenario for ECDSA was
calculated as 10ms, execute, see a delay of 5ms, sleep 15ms, and go on with
life.

This keeps burning people, might as well fix it now.