RE: Support for ECB

I agree that if ECB mode were being exposed solely to avoid specifying CTR fully, then that would be a bad thing. However, I am concerned about interoperability with existing algorithms and protocols that use ECB for good and justifiable purposes. For example, BitLocker uses AES-ECB to derive the IV for a disk block (see http://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608.pdf for the definition of IV_s in section 4.2). 

-----Original Message-----
From: Wan-Teh Chang [mailto:wtc@google.com] 
Sent: Wednesday, September 5, 2012 3:03 PM
To: public-webcrypto@w3.org
Subject: Re: Support for ECB

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? 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 Friday, 7 September 2012 06:09:58 UTC