1793429 - ECDH SubtleCrypto.deriveBits does not correctly handle null length

Status: UNCONFIRMED

(Core :: DOM: Web Crypto, defect, P3)

Description

[Filip Skokan]

Attachment: Screenshot 2022-10-03 at 14.04.37.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36

Steps to reproduce:

const kp = await crypto.subtle.generateKey({name:'ECDH', namedCurve: 'P-256'}, true, ['deriveBits'])
await crypto.subtle.deriveBits({ name: kp.publicKey.algorithm.name, public: kp.publicKey }, kp.privateKey, null)

Actual results:

DOMException: Data provided to an operation does not meet requirements

Expected results:

An ArrayBuffer with the full generated secret should be returned as per the ECDH algorithm definition in https://w3c.github.io/webcrypto/#ecdh-operations (Derive Bits operation).

For ECDH (and in the future X25519, and X448) passing null is a way of asking for the maximum bits to be returned. This is currently the case for all webcrypto implementation except firefox.

This bug is observed in both old and recent versions of Firefox.

Comment 1

[Filip Skokan]

Strike the "This is currently the case for all webcrypto implementation except firefox." from my report, i'll be opening a bug report for chromium as well.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:keeler, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 3

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

Note that the IDL as currently defined by the spec doesn't allow length to be null anyway: https://github.com/w3c/webcrypto/issues/322

Comment 4

[Kagami Rosylight [:saschanaz] (they/them)]

For ECDH (and in the future X25519, and X448) passing null is a way of asking for the maximum bits to be returned. This is currently the case for all webcrypto implementation except firefox.

I doubt this is the case since Blink also fails WPT. https://wpt.fyi/results/WebCryptoAPI/derive_bits_keys/ecdh_bits.https.any.html?label=experimental&label=master&aligned

Comment 5

[Filip Skokan]

(In reply to Kagami :saschanaz from comment #4)

For ECDH (and in the future X25519, and X448) passing null is a way of asking for the maximum bits to be returned. This is currently the case for all webcrypto implementation except firefox.

I doubt this is the case since Blink also fails WPT. https://wpt.fyi/results/WebCryptoAPI/derive_bits_keys/ecdh_bits.https.any.html?label=experimental&label=master&aligned

I said as much in my own comment (since i cannot edit the main body). Chromium bug has been filed as well and all other non-browser implementors do conform to the null behaviour and pass the WPTs.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Ah sorry. In that case you can also edit your initial post.

Also note that Safari just coerces null to 0 and not really detects null. Summary: every existing browser implementation deviates from the spec.

Comment 7

[Filip Skokan]

(In reply to Kagami :saschanaz from comment #6)

Ah sorry. In that case you can also edit your initial post.

Also note that Safari just coerces null to 0 and not really detects null. Summary: every exiting browser implementation deviates from the spec.

I am unable to edit the original body. Or I just don't know how.

WebKit's behaviour on the surface passes the WPTs which is why, from a developer standpoint, behaves correctly in this matter. Where it is incorrect is when 0 is passed but that's a useless behaviour anyway.