Re: JS code examples for ACTION 43

On Fri, Sep 7, 2012 at 12:11 AM, Vijay Bharadwaj
<Vijay.Bharadwaj@microsoft.com> wrote:
>> Line 121: aesAlgorithm contains AesCbcParams, rather than AesKeyGenParams ( http://www.w3.org/2012/webcrypto/WebCryptoAPI/#dfn-AesKeyGenParams )
>
> I think this type of (understandable) confusion indicates that the algorithm object is too overloaded with parameters right now. It seems to have a different set of parameters for each operation as well as key generation, and the algorithm object you query off a key is some undefined mix of these sets of parameters. As a result, it's unclear how one can operate on algorithm objects (for example check if two algorithm objects are equal or somehow compatible).
>
> This goes back to ISSUE-12, which we should probably revisit after FPWD.

No more than PKCS#11, CDSA, or CNG with their various
algorithm-specific parameter structures.

That said, I do agree the API does have an element that feels "ugly" here.

I'd encourage people who feel the same to take a look at some of the
existing APIs (like CryptoJS - http://code.google.com/p/crypto-js/ -
or SJCL - http://bitwiseshiftleft.github.com/sjcl/doc/ ) about an
entirely different construct for dealing with those, that takes better
advantage of JS concepts such as currying.

>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi@google.com]
> Sent: Wednesday, September 5, 2012 4:58 PM
> To: David Dahl
> Cc: public-webcrypto@w3.org Working Group
> Subject: Re: JS code examples for ACTION 43
>
> 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 Friday, 7 September 2012 21:56:12 UTC