4 ms·
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 pr
by ZoFreX 12y ago
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)
- tedunangst 12y agoPeople like their crypto to run faster than "maximally pessimized".
- kaoD 12y agoBut they also like their crypto secure :P
- sdevlin 12y agoA 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.
- ZoFreX 12y agoI 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.
- bascule 12y ago> 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) https://en.wikipedia.org/wiki/Blinding_(cryptography) It's a commonly used method used to implement things like RSA in constant time.
- sdevlin 12y agoI 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.
- deleted 12y ago[deleted]
- bascule 12y agoYes, 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.
- sdevlin 12y agoI guess I'm still unclear how that would work in the context of AES. Or really any symmetric construction, come to think of it.
- bascule 12y agoIt 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.
- divegeek 12y agoThe 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 http://rd.springer.com/chapter/10.1007%2F11935070_14
- samspot 12y agoConstant time is the defense recommended in the article :)