-
Notifications
You must be signed in to change notification settings - Fork 17.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConstantTimeCompare uses less time when length differs and no longer suggests equal length slices #47075
Comments
Dup of #31355, closing. The panic -> return 0 behavior changed in 2014. |
What about something like: krolaw@eb2cea3?branch=eb2cea3005b63eafc2a098667b9484bde689f6c0&diff=split |
@krolaw Not sure what that's trying to fix. Sure, we could make |
@randall77 Thank you for your enlightening response. I hadn't considered different memory locations to have different timing. I had only presumed that making the number of memory accesses constant (or proportional to attack input) would be sufficient. However, wouldn't the changes to the count of memory accesses be far easier to detect than changes in memory access locations? Ignoring memory pattern access timing differences, I'm not sure how the length of x is leaked by timing. If x is the secret trying to be broken, then isn't the number of accesses constant as the same x is used every time? |
Sure.
There's a loop in your code that runs
Why is the same |
What version of Go are you using (
go version
)?master
Does this issue reproduce with the latest release?
yes
https://github.com/golang/go/blame/master/src/crypto/subtle/constant_time.go#L12
ConstantTimeCompare used to panic when len(x) != len(y), now it simply returns zero. Documentation no longer suggests that it be called with two equal length byte slices. Therefore, a dev may expect this function to always take constant time regardless of whether len(x) != len(y), and may provide an attack vector. i.e. an attacker may be able to find the length of the key/password/etc reducing the amount of work required to break in.
The text was updated successfully, but these errors were encountered: