timingSafeEqual functionality

[jespertheend]

Nodejs has the built in timingSafeEqual(a, b) function.
Are there any plans for getting this in SubtleCrypto as well?

[panva]

This would be a very welcome addition.

[jespertheend]

I'd like to add this to the spec, but I haven't done any spec work this big before. Do you think this would be a good first bug?

[twiss]

Hey 👋 Thanks for the proposal. While I think this addition could make sense for SubtleCrypto, it would seem to be out of scope for the new charter that the WebAppSec WG is planning to adopt, which is more focused on maintaining the API (making sure it stays secure, adding more modern algorithms, etc) rather than adding new features.

In addition, there's some overlap here with Constant-Time WebAssembly, and there's some question whether low-level crypto operations (which rely on constant-time comparisons) may make more sense to implement in Web Assembly. For example, note that verifying an HMAC is already supported as a higher-level operation in Web Crypto. Do you have any other concrete use cases of a constant-time comparison function that aren't covered by Web Crypto already but that you believe would make more sense to implement in JavaScript than WebAssembly?

Regardless of the above, before we specify this, there needs to be interest from implementors first. We could of course try to find out if there's interest, but with Constant-Time WebAssembly (hopefully) around the corner, IMHO this seems lower priority than the maintenance work that needs to happen, so personally I would wait for both of those to happen, and then re-evaluate whether this is needed.

[jespertheend]

Thanks for the info, sounds good 👍

I needed the functionality server side in Nodejs. I ended up using the non standard timingSafeEqual(a, b) but I was a bit surprised there was no equivalent in the subtle interface.
I'm not sure if there's any use case outside of Nodejs, perhaps it could be useful in Deno.

My specific use case is that I generate a random password and send it to the client while storing a digest in my database.
Then to authenticate the user sends the generated password and I compare its digest with the stored one using timingSafeEqual.
But perhaps there is a better way to do this that I'm not aware of?

[twiss]

No, makes sense. Technically speaking, comparing hashes is probably less timing-sensitive than certain other operations, because with a strong key derivation function (such as Argon2 or scrypt), learning anything about the hash should not reveal anything about the password, unless the password is very weak. But nevertheless it's probably good practice for that case, yeah 👍

If both Node.js and Deno are interested in implementing this in Web Crypto, then it may be worth checking with the browsers whether they are potentially also interested in implementing it, to see if it would be worth standardizing.

[tniessen]

My specific use case is that I generate a random password and send it to the client while storing a digest in my database.
Then to authenticate the user sends the generated password and I compare its digest with the stored one using timingSafeEqual.
But perhaps there is a better way to do this that I'm not aware of?

This sounds fine, assuming you also use a random salt for each stored digest :)

If both Node.js and Deno are interested in implementing this in Web Crypto

In general, I do believe that timing-safe comparisons are an essential component to any system that uses low-level cryptographic features and I am not generally opposed to adding it to WebCrypto.

That being said, JavaScript is not good for using low-level cryptographic features without introducing a ton of side channels. For example, it turns out to be difficult just to test timingSafeEqual within Node.js core, most likely due to optimizations that V8 applies to the surrounding code.

WebAssembly, for example, allows much better control over side channels than JavaScript and still cannot provide timing safety, which is the primary reason behind the constant-time WebAssembly proposal.

The main use case of timingSafeEqual in Node.js is to validate untrusted inputs against known secrets, which is exactly what @jespertheend described, and which is much more common on the server than in web browsers.

[jasnell]

Just revisiting this. For Cloudflare Workers, we are looking at the possibility of implementing crypto.subtle.timingSafeEqual(a, b) as an extension to SubtleCrypto with the same semantics as Node.js' implementation. We want to make sure that doing so is not going to conflict with any standards work here. I'm happy to write up spec text for this.

/cc @twiss @tniessen

[twiss]

Just revisiting this. For Cloudflare Workers, we are looking at the possibility of implementing crypto.subtle.timingSafeEqual(a, b) as an extension to SubtleCrypto with the same semantics as Node.js' implementation.

Alrighty 👍 Looking at Node.js's docs, just one comment I'd have regarding

When both of the inputs are Float32Arrays or Float64Arrays, this function might return unexpected results due to IEEE 754 encoding of floating-point numbers. In particular, neither x === y nor Object.is(x, y) implies that the byte representations of two floating-point numbers x and y are equal.

I would perhaps suggest to instead restrict the input types, and do the same check that getRandomValues does, i.e.

If array is not an Int8Array, Uint8Array, Uint8ClampedArray, Int16Array, Uint16Array, Int32Array, Uint32Array, BigInt64Array, or BigUint64Array, then throw a TypeMismatchError and terminate the algorithm.

(we could come up with a name for this set, if it makes things simpler, e.g. "integer array views").

We want to make sure that doing so is not going to conflict with any standards work here. I'm happy to write up spec text for this.

Hmhm. Other than the above, I don't see any issues or risks for conflict, but having some spec text for this would probably be valuable 👍 If there's interest from other implementers, submitting it to the WICG might also make sense.