Hacker News Reader

Comment by ZoFreX | Hacker News Reader

I'm really wary of the "don't invent your own crypto" mantra, so I want to venture an idea I had here, rather than writing any code for it:

I understand the problems with adding a random delay to try to add "noise" to the measurements, but what if the delay was non-random? Specifically, what if the delay was calculated to make the whole operation always take constant time?

Example:

User input comes in on thread A. Thread A sends the request to thread B and delays for time t. Thread B does the encryption and sets the result. Thread A resumes and returns the result.

If we pick 't' such that it is always larger than the amount of time it takes to do the operation, any timing differences observed by the attacker won't be correlated with the timing of the cryptographic operations. I think.

(NB: it could be something other than threads, such as "microservice B" instead of "thread B", that particular detail isn't important)

View on HN

A better strategy (and an area of research for Dan Bernstein, author of the referenced paper) is to design crypto that doesn't leak this kind of side-channel information. See, for example, his Salsa20 family of stream ciphers.

I know that is a better strategy, but it's also a much much harder strategy :) Even a well designed cipher could end up leaking info in practice due to compiler quirks or implementation mistakes.

People like their crypto to run faster than "maximally pessimized".

But they also like their crypto secure :P

The best way to fix this is to eliminate the S-box lookup, thereby making AES constant-time.

For example: http://rd.springer.com/chapter/10.1007%2F11935070_14

> I understand the problems with adding a random delay to try to add "noise" to the measurements

Actually, this isn't problematic at all... it's called random blinding: https://en.wikipedia.org/wiki/Blinding_(cryptography)

It's a commonly used method used to implement things like RSA in constant time.

I think he's talking about something like:

  c = encrypt(k, m)
  sleep(rand())
  return c

Which is not what blinding is. Blinding is not really about adding a random delay as much as it is about preventing an attacker from controlling inputs to variable-time functions.

Also, it's not clear how blinding could be applied to AES.

Yes, okay, however my point was we don't actually need constant-time operation if the timing is uniformly random. Clearly that doesn't mean we introduce a random sleep, but it means we carry out computations in a way that timings aren't data-dependent and an attacker can't separate signal from noise.

I guess I'm still unclear how that would work in the context of AES. Or really any symmetric construction, come to think of it.

It isn't used for symmetric encryption algorithms. They're more easily made verifiably constant time as described in the blog post.

It's a common way to protect something like RSA from timing sidechannels, however.

Constant time is the defense recommended in the article :)

Reply on news.ycombinator.com