Re: Support for ECB

Rope is useful for many things :) 

In general, this doesn't make me freak out.  I definitely see the benefit it would provide for polyfilling, having just built implemented CCM on top of PyCrypto using their ECB facility.  Developers using this API are going to have to choose modes anyway, and we can put some notes in the spec that ECB SHOULD NOT be used for actual data encryption.  

--Richard


-- 
Richard Barnes
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Saturday, September 1, 2012 at 8:25 AM, Ryan Sleevi wrote:

> I'm not sure how controversial this will be, so I figured I'd take a quick poll before filing an ISSUE or adding it to the spec.
> 
> It seems to me that supporting ECB, while dangerous, will be desirable to support polyfill. For example, an implementation that doesn't support GCM/CCM can polyfill them atop an ECB implementation. Likewise, an implementation of CTR where the block counter was in the high-order bits, or that used a LSR, could polyfill their CTR implementation atop ECB. 
> 
> Likewise, if an implementation needed to support alternative padding schemes, or modes such as CTS, may need ECB to accomplish this.
> 
> However, ECB in and of itself is trivial, since it's essentially 'naked' AES. 
> 
> So how does the WG feel about adding ECB? Is it too dangerous to even mention, or are the benefits for polyfill implementations enough to merit specifying how it behaves? I'm not trying to suggest that it be advocated, but providing the implementation does seem at least somewhat meaningful. 
> 
> Of course, ECB mode can be used to negate tainting, since an implementation might have a key flagged as ECB, but content script could then implement CTR, CBC, CCM, etc atop that single mode. I'm not sure how strong a negative that is. 
> 
> The counter-argument is that an implementation "could" always implement ECB/GCM/CBC etc by bootstrapping the AES tables. This is what is done by CryptoJS and SJCL. However, such a scheme negates whatever key storage properties are supposed to be afforded by this API. 
> 
> Reactions?

Received on Monday, 3 September 2012 05:27:13 UTC