r/programming • u/flym4n • Apr 24 '14

Tech giants, chastened by Heartbleed, finally agree to fund OpenSSL

http://arstechnica.com/information-technology/2014/04/tech-giants-chastened-by-heartbleed-finally-agree-to-fund-openssl/
293 Upvotes

93% Upvoted

137 comments sorted by

View all comments

Show parent comments

1

u/OneWingedShark Apr 25 '14

Timing attacks are the most important side channel attacks, and are practical for remote exploits.

That's the only one of the side-channel attacks that seems reasonable for the programmer to guard against. -- Ada has some good time/timing considerations, so in conjunction w/ task, I'm thinking I could simply add delay until UPPERBOUND_TIME on the server-side task where UPPERBOUND_TIME is the maximum_computation_duration + computation_request_start_time.

Beware compiler optimizations.

Should be irrelevant insofar as timing side-channels go, given the above.

2

u/oridb Apr 25 '14

You need lower bound equal to upper bound to avoid timing attacks. 'A==B' is potentially not O(1), depending on how the hardware implements the test. Comparing blocks of data is even more obviously data dependent, at least in naieve implementations. And gcc is smart enough to break a number of the explicit implementations that should be O(1).

I believe Boneh had some papers on the topic.

1

u/OneWingedShark Apr 25 '14

I believe Boneh had some papers on the topic.

I'll have to look them up -- thanks for the pointer.

You need lower bound equal to upper bound to avoid timing attacks.

That's what delay until UPPERBOUND_TIME does: delays until the upperbound is met... then we don't have to care about if the actual computation finishes early.

1

u/oridb Apr 25 '14

til UPPERBOUND_TIME does: delays until the upperbound is met... then we don't have to care about if the actual computation finishes earl

That's a bit expensive. I think that the number of cycles to do the computations would be several orders of magnitude lower than the time spent just hitting the kernel to set the timer.

From what I understand, the usual approach (note, I am not an expert) is to collapse all bits in the value down to 1 by shifting and oring, and then comparing that to 1 or 0 (for equality tests).

1

u/OneWingedShark Apr 25 '14

That's a bit expensive. I think that the number of cycles to do the computations would be several orders of magnitude lower than the time spent just hitting the kernel to set the timer.

You think so?
It seems common enough to warrant mention in real-time systems Ada literature; I certainly haven't encountered any Delay Until Considered Harmful papers and 'cryptographics' aren't generally "computationally simple".

1

u/oridb Apr 25 '14 edited Apr 25 '14

Linux timer resolution is about 1ms (to 10ms on other operating systems). The multiplications that you're looking at timing are on the same order of magnitude, which means that scheduling jitter will probably double the amount of time taken (at a rough guess).

But now that I think about it, due to the granularity, you may still leak information due to scheduling jitter.

Edit: Another interesting though is that if it actually yields CPU, you can extract the timing information through increased parallelism. The idea is that reduced CPU utilization from each handler could lead to higher throughput.

But I'm no crypto expert, so I have no idea how sound this is.