- From: Aymeric Vitte <vitteaymeric@gmail.com>
- Date: Fri, 15 Feb 2013 14:55:22 +0100
- To: Ryan Sleevi <sleevi@google.com>, Richard Barnes <rbarnes@bbn.com>
- CC: public-webcrypto-comments@w3.org
This reminds me that I should have sent an erratum of my erratum sent for the encryption case related to Issue 22. See http://code.google.com/p/crypto-js/issues/detail?id=73#c3 , issue addressed to cryptoJS and finally accepted. And see following issue (clone) : http://code.google.com/p/crypto-js/issues/detail?id=74 This is a real life use case, current implementation of cryptoJS, contrarly to others, does not process all blocks when it can on "update", then you have to call "final" which closes the encryptor (same as finish below). I don't know who is right or wrong and if there is an official rule for this, but it does not seem unlogical that cryptoJS "update" returns a partial result (same as Ryan explained for process/progress results which are let to the appreciation of the UA), even if other implementations do return "final". But then I can not achieve what I want to do, and I must use a clone method for this. So, Issue 22 can be about encryption too, probably a clone method is needed. Regards, Le 14/02/2013 21:07, Ryan Sleevi a écrit : > On Thu, Feb 14, 2013 at 11:13 AM, Richard Barnes <rbarnes@bbn.com> wrote: >> Suppose I make the following call: >> >> /* my_iv and my_key pre-defined */ >> var my_pt = new Uint8Array(24); >> var my_ct; >> var op = window.crypto.encrypt( >> {name: "AES-CBC", params: {iv: my_iv}}, >> my_key, >> my_pt >> ); >> op.oncomplete = function(e) { >> my_ct = e.target.result; >> } >> >> That is, I've asked the API to encrypt 24 octets -- 1.5 blocks -- of data. However, CBC only operates on whole blocks (unlike CTR, GCM). What should then happen? (Using enc() to represent encryption, and '+' for concatenation) > Your assumption (that CBC only operates on whole blocks) reflects a > spec ambiguity - one that was raised in Sept and filed as > https://www.w3.org/Bugs/Public/show_bug.cgi?id=18953 > > This was clarified in https://dvcs.w3.org/hg/webcrypto-api/rev/0c723a7d29b3 > >> 1) Complete, result = enc(my_pt[0:16]) >> 2) Complete, result = enc(my_pt[0:16]) + my_pt[16:] >> 3) Complete, result = enc(my_pt + padding) >> 4) Error > As reflected in https://dvcs.w3.org/hg/webcrypto-api/rev/0c723a7d29b3 > , it would be 3 - because the AES-CBC mode is defined to use > PKCS#5/PKCS#7 padding. > > I also note that this is related to you using the 'one-shot' form. > > Consider the following: > > var op = window.crypto.encrypt({name: 'AES-CBC', params: {iv: my_iv}}, my_key); > op.process(new Uint8Array(5)); > op.process(new Uint8Array(19)); > op.process(new Uint8Array(7)); > op.finish(); > > For an implementation that supports incremental encryption, the > expected result would be: > > [op.process(5)] > [op.process(19)] > queue an onProgress, with op.result.byteLength == 16 (that is, it > encrypted the 5 bytes from the first process call and 11 bytes from > the second process call to yield 16 bytes CT) > [op.process(7)] > [op.finish()] > queue an onProgress, with op.result.byteLength == 32 (that is, 8 bytes > remaining from the second process call, the 7 bytes from the third > process call, and 1 byte of padding) > > For an implementation that doesn't support incremental encryption > [op.process(5)] > [op.process(19)] > [op.process(7)] > [op.finish()] > onProgress, with op.result.byteLength == 32 (that is, the combined 31 > bytes, plus one byte of padding) > >> Right now, PolyCrypt does (2), because that's what CryptoJS does if you tell it "no padding"; my development branch does (3). I'm pretty sure both of these are wrong, and (1) or (4) should be the outcome. >> >> In terms of the spec, I believe this ambiguity relates to 12.1 / Step 2 / Steps 3/6 (in the branches, respectively). >> >> Thoughts? -- jCore Email : avitte@jcore.fr iAnonym : http://www.ianonym.com node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms Web : www.jcore.fr Webble : www.webble.it Extract Widget Mobile : www.extractwidget.com BlimpMe! : www.blimpme.com
Received on Friday, 15 February 2013 13:52:53 UTC