3 ms·

> http://hackage.haskell.org/package/securemem http://hackage.haskell.org/package/securemem implements constant-time bytestring comparisons for haskell. With th

by runeks 13y ago

> http://hackage.haskell.org/package/securemem http://hackage.haskell.org/package/securemem implements constant-time bytestring comparisons for haskell. With the bonus that the data is scrubbed when GC'd. As far as I understand, this is not sufficient. Some things that are needed in addition are (at least): * constant time math operations (multiply, divide, exponentiation, etc.) * no branching based on secrets (running the code results in no branch conditions based on secret data) Here's an interesting article on implementing a form of Elliptic Curve Cryptography without even local timing attacks: http://blog.cr.yp.to/20140323-ecdsa.html http://blog.cr.yp.to/20140323-ecdsa.html

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 ago
  Properly 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 ago
  This 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 ago
  while 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)

by runeks 13y ago

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 ago
Properly 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 ago
This 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 ago
while 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)