Comment by mike_hearn | Hacker News Reader

Comment by mike_hearn | Hacker News Reader

Parent Full thread

Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in.

Going with JSSE does have the downside that it's less widely used. Browser makers don't patch it with the latest gizmos like they do with OpenSSL. However, it's at least got a full time development team (unlike OpenSSL until very recently), and ultimately if there are odd conformance bugs lurking the only way they'll be shaken out is by people using it for real. Passing the Qualys test is a good start, but for now my little website is ideal because it is unlikely to ever be popular enough to have serious scaling issues and I can tolerate some incompatibility with odd clients.

> can only be obtained by using hand written assembly or hardware

Even that is harder than it looks.

For example, a common way of doing a constant time string compare is:

    $result |= (ord($safe[$i % $safeLen]) ^ ord($user[$i]));

i.e. get the character to compare mod the length, so you wrap around if the length of the two strings is not the same.

Unfortunately the mod operator does not take a constant time on a CPU! If the result is evenly divisible it's faster.

So even in assembly you might not be able to protect from a timing attack. Even if you check your current CPU a new one might be different.

(In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)

(In this case a better way to do the compare is if the strings are not the same length, compare the attackers string against itself, and then return false.)

Is there a reason for using the attacker's string rather than the valid string? Edit: it doesn't seem to me that using the valid string would leak its length unless the attacker knew quite a lot about the target machine.

How long it takes to do the comparison reveals the length of the string being checked, so you have to check the string which the attacker knows the length of already.

> Edit: it doesn't seem to me that using the valid string would leak its length unless the attacker knew quite a lot about the target machine.

It sounds like you are skeptical that timing attacks can be practically exploited. This is a reasonable skepticism that most people go through on initially learning about them. Unfortunately, there are in fact working exploits for this sort of thing.

No, I definitely realize the seriousness of timing attacks. I'm just curious about this particular implementation detail. I would have guessed that using the attacker's length would reveal more about the system than using a fixed length (unless the length of the valid string changed frequently). I'd like to understand why that isn't the case.

Ah, I see, you're assuming the "valid" string is fixed-width across all requests. I guess in that specific case you might be right. But it's easy for that not to be the case: e.g. if there are several different resources an attacker can request that have different-length strings. For example, an attacker might scan for users with short (=bad) passwords by comparing the time it takes to complete an authentication check against various users. So the safe thing to go is to go with the attacker's string.

What is an actual attack scenario where leaking string length mattered?

If you know the length of a user's password, it narrows the search space considerably.

1. Please don't store raw passwords and compare them with strcmp().

2. Less than you'd think. e.g., the total count of all 1 and 2 and 3 digit numbers is only 11% of the count of 4 digit numbers. (And that stat gets worse with just lower case letters.) Searching all shorter passwords ends up being an insignificant amount of time compared to searching all correctly sized passwords.

I agree. Perhaps there's a more practical example?

Question: if you know the attacker doesn't have local access, is it sufficient to simply introduce random response delays to mitigate JVM-JIT level timing differences? Even if you only delayed responses by a few hundred micros on average (with randomness), I imagine all but the smallest amount of fast-path/slow-path entropy would be lost in the noise.

It requires the attacker to acquire more data - perhaps so much data that the attack is not feasible - but it doesn't rule out a timing attack.

It's pretty easy to filter out the randomness using statistics.

As I understand it, the correct thing to do is to derive a sleep time from hashing the request content, along with some secret. This makes the delay "random" from the attackers point of view, but still deterministic and therefore impossible to filter out.

Note: I am not a security person, just an interested bystander. Take this half-remembered advice with a pinch of salt.

That won't work if there's an irrelevant parameter in the request that can be varied. Say spaces ignored somewhere or additional parameters ignored, for instance.

For this case, could one just introduce another mod operation which produces result + 1? In this case:

    ($i + 1) % $safeLen

Even so, I guess the only way to eliminate timing attacks would be to write a set of primitive operations (XOR, AND, OR, ORD,...) which are constant-time (on the supported hardware platform) and only use those wherever the private information is handled. Is this possible to do? Are there any attempts at this?

"Right - it is looking more and more like truly constant time code can only be obtained by using hand written assembly or hardware. In that eventuality, I guess the core crypto code in the JVM will have to be changed to use hand written assembly as well, however, SSL is huge and most of it doesn't need to be constant time (certificate parsing, managing network buffers, message parsing etc). That is often where the bugs creep in."

I completely agree with you there. X.509 is a nightmare and it's not an area where constant time matters at all. Being resistant to buffer overruns and general logic errors is much more important there.

X.509 is a nightmare because it is complex, and the political infrastructure is vulnerable.

There is no reason ciphers like djb's that use data-independent code paths couldn't be integrated into X.509 if the will was there. Totally separate issues.

Reply on news.ycombinator.com