W3C home > Mailing lists > Public > public-webcrypto@w3.org > September 2012

W3C Web Crypto WG - Support for ECB

From: GALINDO Virginie <Virginie.GALINDO@gemalto.com>
Date: Mon, 10 Sep 2012 12:07:20 +0200
To: "public-webcrypto@w3.org" <public-webcrypto@w3.org>
CC: Wan-Teh Chang <wtc@google.com>, Vijay Bharadwaj <Vijay.Bharadwaj@microsoft.com>, Ryan Sleevi <sleevi@google.com>
Message-ID: <076ED1F6CB375B4BB5CAE7873691360703B51CF9E2B5@CROEXCFWP04.gemalto.com>
Dear all,

I guess the trend is to say that including ECB will not help to solve the ISSUE-27 about CTR. So lest treat it independently. 

I would be happy to hear other opinions on ECB inclusion in our specs in addition to Vijay, Wan-Teh and Ryan views.
Useful, not useful ? 


-----Original Message-----
From: Vijay Bharadwaj [mailto:Vijay.Bharadwaj@microsoft.com] 
Sent: vendredi 7 septembre 2012 08:09
To: Wan-Teh Chang; public-webcrypto@w3.org
Subject: 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.

Received on Monday, 10 September 2012 10:07:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:13 UTC