- From: Richard Barnes <rlb@ipv.sx>
- Date: Sat, 25 Jan 2014 09:08:23 +0100
- To: Ryan Sleevi <sleevi@google.com>
- Cc: Jim Schaad <ietf@augustcellars.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
- Message-ID: <CAL02cgR0aPdX1=3J+ExT5LKCzH5rPC07movJQfEo-7i73_9d-A@mail.gmail.com>
I would also note that even if you deny ECB, a sufficiently creative developer could turn CBC or OFB into ECB, by encrypting single blocks with appropriate choices of IV and plaintext. So trying to deny access to raw AES is kind of quixotic. --Richard On Sat, Jan 25, 2014 at 1:09 AM, Ryan Sleevi <sleevi@google.com> wrote: > Bad idea because again, people are not skilled enough? > > I just want to make sure we have consistent criteria regarding the > acceptance/rejection of an algorithm. And, of course, regardless of > specification, there's a question of "Who will implement it if it's > exposed" and "Can it accomplish the goal" (of supporting polyfills). > > I'm particularly hesitant towards that last one - I don't think, at least > for the algorithms given, it's reasonably possible to implement secure > polyfills using such a primitive. > > I also think any AES primitive would argue for a different interface of > sorts, since the primitive case generally has different performance > requirements than the "composed" case. eg: consider 'optimized' > implementations of AES-GCM, AES-CTR, or even AES-CBC - which use some form > of pre-computation or inter-leaving that the current interface wouldn't > support. > > Anyways, I'm not particularly advocating "raw" AES in the first draft, but > neither am I willing to write it off, especially under the basis of "people > will get it wrong", since such a discussion is structurally equivalent to > arguing for VRML over WebGL. > > > On Fri, Jan 24, 2014 at 2:36 PM, Jim Schaad <ietf@augustcellars.com>wrote: > >> Strictly because other people are not skilled enough. This can easily be >> fixed by adding AES-ECB but that just seems to be a bad idea. >> >> >> >> Jim >> >> >> >> >> >> *From:* Ryan Sleevi [mailto:sleevi@google.com] >> *Sent:* Friday, January 24, 2014 2:21 PM >> *To:* Jim Schaad >> *Cc:* public-webcrypto@w3.org >> *Subject:* Re: Bug #23500 - Raw AES Access? >> >> >> >> Jim, >> >> >> >> If I can make sure I understand your objection, it's because you don't >> think other people are skilled enough, nor do you believe polyfills are a >> valid use case? >> >> >> >> On Fri, Jan 24, 2014 at 2:09 PM, Jim Schaad <ietf@augustcellars.com> >> wrote: >> >> I have a problem with dealing with this issue. While I agree that it >> might be useful to allow for having raw ECB access to block encryption >> processes. I think that the drawbacks of people actually have access to >> the ECB mode and thus getting things wrong is probably too great to allow >> for this. I think this is one of those cases where if you want to get a >> funny block mode then forcing an implementer to also provide the block >> encryption algorithm as well is probably worthwhile. >> >> >> >> I would say that this bug should be closed with no action. >> >> >> >> Jim >> >> >> >> >> > >
Received on Saturday, 25 January 2014 08:08:51 UTC