crypto/subtle: ConstantTimeCompare doesn't always run in constant time

[nickvellios]

Type: Potential Exploit
Go v1.17 (Latest)

Problem:

go/src/crypto/subtle/constant_time.go

Lines 13 to 15 in 4711bf3

	if len(x) != len(y) {
	return 0
	}

The ConstantTimeCompare function in crypto/subtle/constant_time.go will return in O(1) if the lengths of both function parameters are not equal, and O(n) if the lengths are equal.

Security concern:

bcrypt's CompareHashAndPassword function uses subtle's constant time compare to combat timing attacks. One could discover the length of a password hash which could be an attack vector when paired with another exploit.

Risk level is low, but any unanticipated leak of data is still a leak and this should be addressed.

Potential solution:

If lengths of x and y are not the same, proceed to compare as normal but in this case, always return 0. I'm open to suggestions.

[randall77]

Dup of #31355, closing.

[jmhodges]

As the original author of the Go bcrypt lib, let me chime in on why this is not a security issue for bcrypt:

The use of ConstantTimeCompare in bcrypt is only given the hashes of the password and those hashes are always the same length.

See the use here:

https://github.com/golang/crypto/blob/5ff15b29337e062d850872081bcd9f4d784f4c25/bcrypt/bcrypt.go#L111-L113

and the slice creation in Hash here:

https://github.com/golang/crypto/blob/5ff15b29337e062d850872081bcd9f4d784f4c25/bcrypt/bcrypt.go#L234-L235

[jmhodges]

(You're not the first person to worry about this! I've gotten this kind of thing wrong before, too. Thanks for making a ticket!)

[nickvellios]

@jmhodges I appreciate your contributions to this issue and the Go project. Thanks for your input.