- From: David McGrew (mcgrew) <mcgrew@cisco.com>
- Date: Mon, 10 Sep 2012 16:53:27 +0000
- To: Wan-Teh Chang <wtc@google.com>, "public-webcrypto@w3.org" <public-webcrypto@w3.org>
Hi Wan-Teh, On 9/5/12 6:03 PM, "Wan-Teh Chang" <wtc@google.com> wrote: >Ryan already summarized my reactions to this proposal in his email, >but it seems useful for me to state them for official record. > >1. The design of the Web Crypto API shows a desire to promote good >crypto practices. Exposing the ECB mode runs counter to this design >philosophy. > >2. One reason we're considering providing the ECB mode is the >difficulty of specifying the CTR mode parameters that support every >counter incrementing function. I think the CTR mode parameters >specified in the draft are sufficient in practice. Does anyone know of >a protocol that puts the block counter in the high-order bits? I don't know of any standards that do counter mode that way. It seems that most have an "increment" function that does addition in the low-order 16 or 32 bits, and assumes big endian integer representation. This certainly goes for the IETF protocols (though they do IVs in different ways). David >Using >LFSR to increment the block counter is attractive to hardware >implementations, but seems awkward for software. > >In summary, I would not object to exposing the ECB mode, but I don't >see a strong need for it. In particular, exposing the ECB mode should >not be our way to avoid specifying the CTR mode. > >Wan-Teh >
Received on Monday, 10 September 2012 17:01:05 UTC