5 ms·
Timing-independent array comparison
- gjm11 17y agoThe title is rather misleading (not the submitter's fault -- it's the title of the original post). It's not "array comparison that's independent of timing", whatever that might have meant, it's "array comparison whose timing is independent of the contents of they arrays". (To avoid side-channel attacks on your crypto.) I think there's an oversimplification in the first section, though it may be a deliberate one for the sake of clarity. Your goal isn't really to know each byte with 95% confidence, it's to know enough about the bits that you can do a small search and be likely to find the right key / hash / whatever. Which means that what you really want to do is to have a model of how the timings (noise and all) relate to the actual values, and keep going until the total entropy of the secret you're trying to extract gets small enough.
- gjm11 17y agoWould whoever downvoted me care to explain why? If I made a mistake, I'd like to learn. If I said something offensive, I'd like to apologize. Thanks!
- NateLawson 17y agoYour first paragraph is correct. Your second is not in most cases. You're right that, in general, once you've guessed enough of a secret, you can just brute-force the rest offline. However, a timing attack is online, so you have to issue a query for each guess. Thus, there is no way to turn this into an offline attack and thus nothing changes about the process along the way. You do the same thing for the last byte as for the first. The other is that entropy has nothing to do with this really. You have to guess bytes sequentially from first to last, you can't gain information about the last byte from the first. Now if the secret is a password and not a cryptographic key or MAC, incremental information does help you. So in this case, you're right. PS. no idea about your downvote