deriveBits length idl does not allow null

[panva]

webcrypto/spec/Overview.html

Lines 1258 to 1260 in 004f26a

	Promise<ArrayBuffer> deriveBits(AlgorithmIdentifier algorithm,
	CryptoKey baseKey,
	unsigned long length);

The SubtleCrypto.deriveBits function length argument's IDL does not allow null to be passed despite there being a special handling for its possible null value in all deriveBits operations, for most it throws but for ECDH, X25519, and X448 it is defined as returning all generated bits.

I believe the length argument of deriveBits should be made nullable like so?

Promise<ArrayBuffer> deriveBits(AlgorithmIdentifier algorithm, 
                         CryptoKey baseKey, 
                         unsigned long? length); 
                                      ^ nullable?

In WPT there are even tests for this behaviour.

https://github.com/web-platform-tests/wpt/blob/3174b85610804424ac4c6c2a194a08220402a00e/WebCryptoAPI/derive_bits_keys/ecdh_bits.js#L58-L66

[twiss]

Hey 👋 It seems you're right. If you feel like making a PR when you're back, it'd be welcome, otherwise I can also do it :)

[panva]

Feel free to do so.

[saschanaz]

But no one is using nullable type for deriveBits, wouldn't changing the IDL also change the behavior? Is this tested by WPT?

• Gecko: https://searchfox.org/mozilla-central/rev/7dffbe62b2caea25ed3b221626d0b82238ce2e9e/dom/webidl/SubtleCrypto.webidl#220
• WebKit: https://searchfox.org/wubkat/rev/f8166f50d036560b0a2553800d1de26b6302b83d/Source/WebCore/crypto/SubtleCrypto.idl#43
• Blink: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/modules/crypto/subtle_crypto.idl;l=49;drc=c3b7c5877ef5262668ee9b5fce7f862326eee7c1

[saschanaz]

In WPT there are even tests for this behaviour.

https://github.com/web-platform-tests/wpt/blob/3174b85610804424ac4c6c2a194a08220402a00e/WebCryptoAPI/derive_bits_keys/ecdh_bits.js#L58-L66

Oops, missed this part.

https://wpt.fyi/results/WebCryptoAPI/derive_bits_keys/ecdh_bits.https.any.html?label=experimental&label=master&aligned says Chrome and Firefox fail the null length tests while Safari passes (how?). Interesting that Safari's implementation is also definitely using non-null length.

[saschanaz]

Eh, so the IDL passes null as 0 to C++ in every browser, and then Safari uses 0 to mimic If length is null: part.

Interesting, should this be specced? 🤔

[panva]

But no one is using nullable type for deriveBits, wouldn't changing the IDL also change the behavior?

Node, CF Workers, Deno, and now Bun as well, correctly implement the null behaviour for ECDH deriveBits.

We're beyond a point where we could remove the behaviour.

I also suspect chrome and firefox could have the correct ECDH deriveBits operation implementation but the webidl conversion coerces null to 0 and we just don't know ;)

[martinthomson]

@saschanaz is correct in that there is no "null" behaviour. The WebIDL definition does not allow for the value to be null. Any value is coerced into a number, with an absent value being turned into a 0.

I think that omitting the argument is a useful bit of ergonomics (not everyone knows the native output size of this function), but I don't see any reason to change the IDL to allow for a null value to achieve that. Using 0 as a sentinel value works perfectly fine in this case, as asking for 0 derived bits is pointless.

I would suggest that we just change the algorithm for ECDH so that it conditions the return of the whole secret on length == 0 rather than length is null. That change is here:

webcrypto/spec/Overview.html

Lines 9662 to 9663 in 004f26a

	<dt>If |length| is null:</dt>
	<dd>Return |secret|</dd>

s/null/0/

This would effectively formalize the Safari behaviour as noted above.

[panva]

@martinthomson There is an interaction to be considered with the get key length op used in deriveKey which also returns null in HKDF and PBKDF2 cases. Such a simple sed is not the way.

I believe changing the IDL is the correct course of action. We have WPTs for this behaviour, indicating the original intention and there are more implementations conforming to it than the opposite.

[martinthomson]

For HKDF, "If length is null or zero" becomes simply "If length is zero". Same for PBKDF2. I don't see any major problem there.

A nullable value makes the IDL and the algorithm more complex. This is simpler.

[panva]

@martinthomson That's not dealing with the fact that get key length returns null for HKDF and PBKDF2. Meaning this is no longer a simple one-liner like change you're suggesting as opposed to fixing the webidl to reflect the original intention as well as a larger number of existing implementations with an actual one-liner.

[martinthomson]

Sorry, I thought that was clear: if you pass the output from getting the length as an argument to deriveBits, then it will coerce to zero happily, no problem.

[twiss]

I think checking for zero instead of null is technically speaking not backwards-compatible. It's a bit of an edge-case (and not really a useful operation to do), but as currently specified, passing 0 should cause an empty ArrayBuffer to be returned, and that's in fact what some implementations do. So I think we should change the IDL, to what seems to have been the original intention.

[martinthomson]

To be clear, what I'm proposing requires a change in Firefox, but I think that it is the better change. A zero-length array can be obtained more simply by other means. And implementations are already non-compatible.

Edit: Note that there is no option here that is strictly backwards-compatible.