- From: Ryan Sleevi <sleevi@google.com>
- Date: Wed, 5 Sep 2012 16:58:14 -0700
- To: David Dahl <ddahl@mozilla.com>
- Cc: "public-webcrypto@w3.org Working Group" <public-webcrypto@w3.org>
On Wed, Sep 5, 2012 at 4:34 PM, David Dahl <ddahl@mozilla.com> wrote: > Hello everyone: > > Arun and I have created a JS example file related to ACTION 43 here: https://github.com/daviddahl/web-crypto-ideas/blob/master/sample-code-fpwd.js > > Please send comments when you get a chance. I can incorporate approved examples later this week. > > Cheers, > > David > Individual notes on correctness: Line 73 - 75: Why not just call "signer.processData(myData)", since "myData" was declared at line 32? Line 121: aesAlgorithm contains AesCbcParams, rather than AesKeyGenParams ( http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-AesKeyGenParams ) Since you're generating a key (line 129), you should be specifying key generation params. var aesKeyGenParams = { name: "AES-CBC", params: { length: 128 } }; To encrypt (line 165), you'd need to specify the parameters as you've done, modulo the concerns below: Line 124: http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-AesCbcParams has the IV as an ArrayBufferView, but the sample code uses base64. Perhaps this should be: iv: toArrayBufferView(window.atob("NjA....==")) Line 157: Seems like it should be a Key object. Line 185: Seems useful to have, especially considering the security of CBC... Line 203 - 209: Am I mistaken that, by storing into a Uint16Array, you're effectively adding an extra 0 byte for each ASCII character? That means that what you're encrypting is not "53kr3t" but "5\03\0k\0r\03\0t" That sort of subtlety scares me, since I fear people will copy the spec as 'good' things. Perhaps this means re-discussing ArrayBuffer[View] as a data type, or it may mean that the toArrayBufferView should be "ASCIIToArrayBufferView" or some other aspect, so that a JS String "53kr3t" is the same as a C/Python/Ruby/etc string of "53kr3t" which is the same as the literal data "0x35, 0x33, 0x6b, 0x72, 0x33, 0x74", and NOT "0x35, 0x00, 0x33, 0x00, 0x6b, 0x00, 0x72, 0x00, 0x33, 0x00, 0x74, 0x00"
Received on Wednesday, 5 September 2012 23:58:42 UTC