crypto.timingSafeEqual is not really time safe?

[elaygl]

After trying to use crypto.timingSafeEqual with two buffers that have different length I've got an exception.

I read the docs and realized that crypto.timingSafeEqual is supporting only buffers with the same length which is contradicting the concept of timing safe compare.

The comparison code:

node/src/node_crypto.cc

Line 6065 in 51e0948

void TimingSafeEqual(const FunctionCallbackInfo<Value>& args) {

Maybe it's worth to implement it like that: https://github.com/vadimdemedes/secure-compare/blob/master/index.js#L12

[bnoordhuis]

See #3043, #3073 and #8040. The current behavior is the product of a stupefying amount of discussion. I think it's unlikely we'll revisit that.

As well, your suggestion is a subtle change in behavior. Too subtle, IMO - it might end up breaking applications in ways that go undetected until it's too late. That risk alone practically rules it out.

[ryangreenberg]

Generally a comparison function that is resistant to timing attacks is used to compare signatures or hashes, which should be the same length by virtue of being generated by a hash function. If you are accepting a user-provided signature and want to compare it in a safe way, it's OK to check the length first and return early, e.g. return a.length === b.length && timingSafeEqual(new Buffer(a), new Buffer(b)). This doesn't reveal any information about the contents that would aid a typical attack.

See https://codahale.com/a-lesson-in-timing-attacks/ for more details (which also does a length equality check).

[jaylattice]

Length checks are timing safe, because they do not depend on time.