3 ms·
Why can't timing be handled external to the scrambling or descrambling operations? Look at the time, do the crypto, then check the time and sleep as necessary s
by dpatru 13y ago
Why can't timing be handled external to the scrambling or descrambling operations? Look at the time, do the crypto, then check the time and sleep as necessary so that this particular operation takes about as much time as the worse-case. Something like:
cryptofunc x = do
begintime <- gettime
result <- purecryptofunc x
endtime <- gettime
sleep (worstcase - (endtime - begintime))
return result
- mantasm 13y agoProperly implemented crypto takes a constant number of instructions to encrypt/decrypt, regardless of key, plaintext, etc. Time to sleep() would vary across processors, os-es, and even load (!), so it's not exactly a workable solution. Not to mention it would be grossly inefficient (Context switch on every crypto primitive? No thanks).
- ema 13y agoThis still would allow side channel attacks on cpu utilization. cpu utilization can be inferred, for example if the attacker has a vm on the same machine, or the attacker can make a second request which completes sooner if the cpu is less utilized.
- axman6 13y agowhile not a completely terrible idea, sleep doesn't give you any guarantee of when it'll wake your code up again, only that it'll be asleep for at least X time. I think this is ok, but someone with more info on these sorts of bugs would be better place to comment. It also seems reasonable to add a random length of time to the sleep time, so that differences in computation time are indistinguisable from the randomness added by the random variable. I could be completely wrong though. (also, you probably need to force with seq or deepseq the result of purecryptofunc before getting the second time, or you might be adding that evaluation time to another part of the code, and then this code becomes just a constant time added to the computation)