Commit
Conflicts: test/spec_utils.rb
- Loading branch information
There are no files selected for viewing
8 comments
on commit 9a81b96
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you know a future ruby implementation will not optimize this in a "return early" version again? Could you add a spec that checks for constant runtime? Maybe an integration spec that does a timing analysis? I'd totally accept if rack would depend on the NaCL ruby bindings to delegate constant time comparisons.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hope this method is not going to be used anywhere. Perhaps I don't understand what it's needed for?
- You can't compare strings in constant time; comparison will always depend on the length of the strings.
- This is probably the most inefficient way to compare two strings. In fact, I don't actually understand what it is accomplishing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mbj I am happy to add some tests that make a loose effort at proving at the time is relative to the length of both strings, and doesn't fast exit. The rest of your suggestions and comments are impossible, excessive or odd.
@headius sure, the difference with this method is that it will always take time relative to the length of the strings, not relative to the content of the strings. It is constant with respect to varying external content (not length), except for the single (safe) fast exit case of the input being empty(edit: different lengths. i'm tired, and it's the weekend, forgive me). You are absolutely correct, that in algorithmic terminology, this is not constant time as in O(1) regardless of the input. In crypto circles, this kind of comparison is generally referred to as "constant time", even though that is a misnomer. A relevant example paper that covers these timing issues can be found here: http://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf. Timing attacks against HMAC are actually somewhat easier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may be true I should handle some encoding details here too, if the method is to be used in a generic fashion. For the current intended use case, where all valid characters are ascii, we do not reveal anything useful in bytesize.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Honestly feel like I'm being trolled here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@headius what it's trying to accomplish is preventing short-circuiting. The phrase "constant time" is being used in regard to two Message Authentication Codes which are fixed-size. The goal is to have them always compare in constant time. Just using "==" will fail fast on the first byte. If we can measure timing information over the course of many requests and see a "signal" when brute forcing various byte combinations, we can use that signal to determine when we've successfully brute forced a single byte of a MAC. It looks something like this:
It's somewhat analogous to picking a lock. Once you've gotten the first tumbler, you can move on to the next one, and the next one until you've picked them all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.

This does not actually test where
secure_compareperforms a constant time string comparison, just that it compares two Strings.