crypto.subtle.encrypt throws wrong error for AES-GCM with 256-bit tag
Reported by
charles....@gmail.com,
Jul 8 2016
|
||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36
Steps to reproduce the problem:
1. Go to a secure page (https)
2. Open the developer console
3. Enter and run the following code:
var plaintext = new Uint8Array([1, 2, 3]);
var additionalData = new Uint8Array([4, 5, 6]);
var iv = new Uint8Array([1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16]);
var keyBytes = iv;
window.crypto.subtle.importKey("raw", keyBytes, {name: "AES-GCM"}, false, ["encrypt"])
.catch(function(err) {console.log("Import key failed: " + err.name)})
.then(function(key) {return window.crypto.subtle.encrypt({name: "AES-GCM", iv: iv, additionalData: additionalData, tagLength: 256}, key, plaintext)})
.then(function(ciphertext) {console.log("It worked.");})
.catch(function(err) {console.log(err.name);});
What is the expected behavior?
It displays "OperationError"
What went wrong?
It displays "TypeError"
Did this work before? N/A
Chrome version: 51.0.2704.106 Channel: stable
OS Version:
Flash Version: Shockwave Flash 22.0 r0
Note that is does display the correct errors for other invalid tag lengths, such as 24, 48, 72, 95, and 129.
Also, the decrypt method has the same problem.
,
Jul 8 2016
Works for me when tested in 51.0.2704.103. I will try on .106 like the original bug reporter too, but I don't see any obvious problems in the code. Note that 256 is a bit different from the other invalid tagLengths as it is a violation of the [EnforceRange] constraint on tagLength (octet) so it essentially fails during normalization rather than when executing the algorithm and checking the tagLength. That said it should fail with TypeError either way. @charles: Can you confirm that you are able to reproduce? Meanwhile I will try on .106 and canary as well.
,
Jul 8 2016
I'm wrong about this bug. The code does fail with TypeError, but I thought it should fail with OperationError. That's because the editor's draft of the spec at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#aes-gcm-operations says that bad key lengths should throw an OperationError. But you're right, that check happens after normalize an algorithm, and the registration at https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html#aes-gcm-registration says the tagLength should be an octet with EnforceRange 0-128. Converting 256 to an octet should throw a TypeError, which is what happens. I'm not clear on the effect of EnforceRange in the IDL definition. Should values between 129 and 255, inclusive, be rejected when normalizing the algorithm? If so, should they be rejected with TypeError? Right now, those kinds of values cause an OperationError. In any case, my bug report is an error. It throws TypeError and should throw TypeError. I'm not clear on whether values 129-255 should also throw TypeError or not.
,
Jul 8 2016
When citing spec bugs, please use https://github.com/w3c/webcrypto The spec at dvcs.w3.org is unmaintained and out of date/misleading.
,
Jul 8 2016
My interpretation is that: * Anything < 0 or > 255 throws a TypeError, due to violating EnforceRange octet during algorithm normalization. Note that "Octet" is an unsigned type per https://www.w3.org/TR/WebIDL/#idl-octet * Anything >=0 and <= 255, but that is not one of the explicitly supported tag lengths throws an OperationError, per the language in Web Crypto spec This is what I believe to have implemented for Chrome.
,
Jul 9 2016
Makes sense to me. Sorry for opening this bug.
,
Jul 9 2016
,
Jul 9 2016
|
||||
►
Sign in to add a comment |
||||
Comment 1 by sleevi@google.com
, Jul 8 2016Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug