Contant Time Comparisons are *not* Always Constant

[bcgit]

Contant Time Comparisons are *not* Always Constant

[cipherboy]

@StrangeWill In general, unless there's a fixed upper limit to compare against, you're going to at least leak the timing information one of the two buffers. This leaks the timing information that the two are different. Most other implementations (e.g., Go's which bails early like ours does, the JDK's which bases on the first passed array (which you'll know is shorter if you passed the second array and it is longer -- or can tell the size of the second array if you control the first array), or OpenSSL which pairs short-circuiting length comparisons with the constant time comparison over two equal-length arrays) have similar issues.

If your implementation depends on not knowing the size of either of the two arrays, I'd suggest copying them into a length-prefixed, zero-padded byte array and then perform the constant time comparison over the two.