AES-CTRwith encryption error
Reported by
microshi...@gmail.com,
Jun 18 2017
|
|||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Steps to reproduce the problem: If you ran code from aes_test.js in Chrome you'll got equal values for `enc` and `item.enc`. Mozilla has different value for AES-CTR 128 with length 1 I tried the same script with OpenSSL and had got the same value as Mozilla here is my HEX values for AES-CTR 128 length: 1 Chrome: c1bda220dfacde34bba727b5d02c7e5d778a43827fcdf7a38f19f7daa0e8b68c Mozilla and OpenSSL: c1bda220dfacde34bba727b5d02c7e5db0044f0482a6e2bd951ded542cdcfc0a What is the expected behavior? What went wrong? AES-CTR 128 length: 1 has different encrypted value than Mozilla and OpenSSL. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 58.0.3029.110 Channel: n/a OS Version: OS X 10.12.5 Flash Version:
,
Jun 22 2017
Thanks for the report! I can reproduce, but may not get around to investigating until Friday.
,
Jun 23 2017
This looks like a bug in Firefox's implementation. @davidben: Can you confirm my analysis below? The issue is with how the counter is being incremented when using length = 1 bit. In binary, the counter starts off as: ...0101 Firefox is then incrementing it to ...0110 Whereas Chrome increments it to: ...0100 This is why the ciphertext agrees in the first 16 bytes, but then differ in the last 16 bytes. From what I can tell, Chrome is doing the right thing here, since a length of 1 bit was requested (so should only be modifying the last 1 bit of the counter block when incrementing). This is consistent with "B.1 The Standard Incrementing Function" as described in http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38a.pdf Thanks for the report! This does point to a lack of cross browser coverage of AES-CTR by the W3C test suite -- I'll see if I can get this test added upstream so we can shake out this incompatibility. Cheers.
,
Jun 23 2017
...why does WebCrypto let you use a 1-bit counter? Sure, I guess if that is a thing that is allowed, it probably means to only increment the bottom bit. But that shouldn't be in this API to begin with. |
|||
►
Sign in to add a comment |
|||
Comment 1 by ranjitkan@chromium.org
, Jun 19 2017