Possible timing problem with Bytes.equal() about tink

[thaidn]

Unless there's a cleverer attack that I'm unaware of, the timing side channel attack allows recovering the secret HMAC value byte-by-byte. This attack is thwarted if Bytes.equal(s1, s2) compares SHA256(s1) with SHA256(s2). Yes, the adversary knows what bytes being compared, but that's not enough because they need to find a pre-image that hashes to those bytes.

More concretely, they know SHA256(s1) and they can use the timing side channel to figure out the first byte of SHA256(s2). Now what? They need to find s1' such that its first byte matches the first byte of SHA256(s1) and its second byte matches the second byte of SHA256(s2). Before long, the adversary has to reverse SHA256.

[thaidn]

Bytes.equal is mostly used to validate MAC, thus we're already doing what you're suggesting, right?

[SalusaSecondus]

No. The problem is that one of the MACs is attacker controlled. So, if one value is unknown (the correct MAC calculated under a secret key) and the other is attacker controlled, then if Bytes.equal() has a timing signal, an attacker can use this to guess the secret MAC. (This is why you are using this standard constant-time algorithm.)

Unfortunately, the JVM and JIT does terrible things to constant time algorithms and can break them horribly. By calculating a MAC under a random key of the values and then comparing those MACs, even if the algorithm isn't constant time, the attacker has no way of knowing what bytes are being compared to what bytes and cannot execute the attack.

NCC Group wrote about an extremely similar defense they call Double HMAC Verification. I prefer my proposed modification because it doesn't require knowledge of the HMAC key (and may be applied to things other than HMACs) and because it is even more randomized than reusing a key multiple times dor the comparison.

[thaidn]

Ah I now see what you meant.

Did NCC Group even publish their paper? I want to understand why Bytes.equal doesn't work as they claimed.

Also not sure we need to use double HMAC. Why isn't applying a round of SHA256 enough?

@bleichen @przydatek

[katrielalex]

I have no idea about JVM and constant time algorithms but I don't think a round of SHA256 would be enough, because the attacker could also compute it and would thus know what bytes are being compared. Computing a MAC under a (secret) random key does not reveal that to the attacker.

[bleichen]

Thai, I'm just seeing your e-mail. If you want us to participate in this question, then you have to give us some context about what the question actually is, or give a link to some previous discussions.

…

On Thu, Feb 22, 2018 at 6:29 PM, Thai Duong ***@***.***> wrote: Ah I now see what you meant. Did NCC Group even publish their paper? I want to understand why Bytes.equal doesn't work as they claimed. Also not sure we need to use double HMAC. Why isn't applying a round of SHA256 enough? @bleichen <https://github.com/bleichen> @przydatek <https://github.com/przydatek> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#73 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AYx_3pP8P03Jt6fL6FXRXXB2lOV15PcRks5tXaPzgaJpZM4SOtAV> .

[bleichen]

Looks like overkill to me.

I've been trying to find compilers that would convert functions like Bytes.equal() into
something that is non-constant time. So far without success. Are there examples?

Typically, compilers rather try to remove branches rather than to add new ones to
avoid the cost of branch mispredictions.

[hillbrad]

How I feel about that blog being cited to @thaidn and @bleichen : https://www.theonion.com/bush-finds-error-in-fermilab-calculations-1819566086

(Is is overkill, was intended as advice for naive developers, and it does weaken the HMAC verification against brute force guessing to the collision probability of the hash function.)

[SalusaSecondus]

@hillbrad Thank you. I'm also going to try to track down (and then make public) the other data I found. However until I can find something more solid, we should probably consider this issue closed.

[thaidn]

Thanks folks. Closing this bug, but please feel free to reopen once you've gathered more data.

[tarcieri]

It should be possible to use the PrintAssembly command line option for the JVM to have HotSpot emit the generated assembly, which can then be verified for constant-time operation on an architecture-by-architecture basis.