5 ms·

Incredible, but nothing a little sleep(rand()) won't solve.

• sophacles 17y ago
  Not really, if this attack is doable over the internet, which will have latencies randomly[1] distributed (in a normal curve), rand does not actually do anything, well maybe require a few more sample points to get that noise out.
  • naz 17y ago
    That makes sense, maybe sleep(rand(1.0 - time_spent))
    • naz 17y ago
      Or just sleep(1.0 - time_spent)
      • JacobK 17y ago
        Or just don't short circuit ever, and do the entire computation every time.
• codahale 17y ago
  You may want to read this: http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf Adding jitter will not defeat timing attacks unless the jitter is dependent on the input, like blinded RSA.
  • commiebob 17y ago
    What if you did something like (using the example from the article) A value which shares no bytes in common with the secret digest will return immediately; a value which shares the first 15 bytes will return 15 compares later. You keep track of the time while doing the comparison, then before spitting back the result you feed the amount of time to a separate function that will sleep (or whatever) a certain amount of predetermined time so that all results process in the same time. I realize this is a bit excessive, and will slow down your code quite a bit, but if you are really that worried about this type of attack, why not?
    • codahale 17y ago
      You don't really need to. You can guarantee that the right HMAC and the wrong HMAC both take exactly the same amount of time to compare by using a constant-time algorithm like the one in the article without dealing with non-portable, unreliable timers. (In some languages—hi Ruby!—you might not even have access to reliable millisecond-resolution timing.)
• eru 17y ago
  Sleeping for a random amount of time will make it more difficult to mount a timing attack. But not impossible in theory. You just have to do more statistics --- significance tests and the like.
  • anamax 17y ago
    Why not sleep a variable amount of time, so all calls take the same amount of time?
    • niyazpk 17y ago
      As naz pointed out, you can use sleep(1.0 - time_spent) to accomplish this. The downside is that while the solution given in the OP will use a constant amount of time, that constant amount of time itself is not fixed. When over the years processors get faster, the code can execute faster, but in the above case it cannot.
      • anamax 17y ago
        > When over the years processors get faster, the code can execute faster, but in the above case it cannot. Sure it can. You can drop the limit whenever you change processors. In fact, you can tune the limit for a given call to be the max time taken by that call. As the implementation or resources change, the limit changes.
        • codahale 17y ago
          You're better off just using a constant-time algorithm which uses the same number of operations for all inputs. Few systems, if any, have sub-nanosecond-resolution timers, let alone thread schedulers which have quanta of that size.
          • anamax 17y ago
            > You're better off just using a constant-time algorithm which uses the same number of operations for all inputs. That's easier said that done. Also, you have to come up with one for every security-relevant operation. And, "algorithm" isn't the issue, implementation is. Given caching and the like, that's really hard to do. An easy way to implement the "sleep to worst case" idea is to simply time each call and keep track of the max. If a given call instance returns in less time, sleep the difference. (It's probably good to add a decay mechanism.)