Re: my revised proposal for ECB (was: Support for ECB - proposal for a decision)

How should we then handle cases where length is not a multiple of 16? 
And when does it make sense to encrypt any other lengths?

I think adding a padding scheme here is a bad idea, as it will endorse 
using ECB as a "first class citizen" encryption function for streams of 
data. All of the examples given in this thread as reasons to add ECB 
(using ECB is an building block to optimize or create other encryption 
schemes), will only encrypt lengths that are multiple of 16.

Cheers,
Håvard

On 10/04/2012 03:09 PM, Harry Halpin wrote:
> Please read and comment!
>
> I suggest we get consensus on this proposal on our next call.
>
> Myself, I can see myself agreeing with all parts except possibly 2., 
> even though its a standard requirement, it seems odd making ECB have 
> such special parameters.  However, the magic words are "I can live 
> with that", which I can.
>
>
> On 10/02/2012 12:08 AM, Zooko Wilcox-OHearn wrote:
>> Folks:
>>
>> I apologize again for being late to today's call. Here is my current
>> proposal in light of today's discussion.
>>
>> 1. We agreed that WebCrypto should specify ECB. (This is a change from
>> my earlier position. I agree to specifying ECB because it could be
>> more efficient to compute AES on a number of blocks at once, such as
>> when implementing an encryption mode of operation.)
>>
>> 2. I propose that the ECB function take a number of input bytes which
>> is an integer multiple of 16, and raise an exception if the input is
>> of a different length. That's the standard requirement for ECB.
>>
>> 3. I propose that the API and documentation clearly signal that ECB is
>> not an encryption mode. Specifically, I propose that the algorithms
>> are grouped like this:
>>
>> • Public key encryption: RSA-OAEP, RSAES-PKCS1-v1_5
>> • Public key digital signature: ECDSA, RSA-PSS, RSASSA-PKCS1-v1_5
>> • Key agreement: ECDH, Diffie-Hellman
>> • Authenticated encryption: AES-OCB, AES-GCM
>> • Unauthenticated encryption: AES-CTR, AES-CBC
>> • Message authentication code: HMAC-SHA256
>> • Key-derivation functions: HKDF, PBKDF2
>> • Primitives: AES-ECB, SHA256
>>
>> And I propose that the documentation of the AES-ECB function say
>> something like this:
>>
>> "NOTE: This function does not, except in special cases, conceal the
>> content of the message and cannot, except in special cases, be used
>> for encryption. It is included only for the use of cryptographers to
>> implement other cryptographic algorithms. For an encryption function,
>> please see the functions listed under Authenticated Encryption or
>> Unauthenticated Encryption."
>>
>>
>> As a framing note: I care a lot about the security of apps. My work is
>> sometimes used by people who risk suffering not just financial loss
>> but imprisonment, torture, or murder, if the confidentiality and
>> integrity that they need from their apps isn't there. Our work here is
>> destined to be used that way, too. People are already using web apps
>> such as Crypto.cat to say things that could get them murdered or
>> imprisoned if the wrong people overhear, and this trend will increase
>> greatly in the coming years.
>>
>> Older crypto libraries such as Crypto++ ¹, Java ², and .NET ³
>> typically included ECB among a list of encryption modes, sometimes
>> with a warning note in the documentation. This has been repeatedly
>> demonstrated to lead to insecure apps which use ECB mode for
>> encryption of secret plaintexts. It is not hypothetical that ECB
>> *could* lead to this -- it is established fact that it has done so,
>> many times. It is such a common pattern that another instance of it
>> was announced while we were having this very conversation: ⁴. In that
>> case, a library which included ECB (with warning documentation)
>> adjacent to CBC mode and CTR mode led to web sites in which attackers
>> could take over the sessions of authenticated users. A different
>> library (which I wrote) which excluded ECB mode was not vulnerable to
>> that attack.
>>
>> So it is important to me that the WebCrypto standard doesn't replicate
>> these practices which have led to these vulnerabilities. My proposal
>> above will, I hope, avoid that.
>>
>> Regards,
>>
>> Zooko Wilcox-O'Hearn
>>
>> Founder, CEO, and Customer Support Rep
>>
>> https://LeastAuthority.com
>>
>> ¹ http://www.cryptopp.com/wiki/ECB_Mode
>> ² 
>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#Cipher
>> ³ 
>> http://msdn.microsoft.com/en-us/library/system.security.cryptography.ciphermode.aspx
>> ⁴ http://lists.w3.org/Archives/Public/public-webcrypto/2012Sep/0146.html
>>
>

Received on Thursday, 4 October 2012 15:22:37 UTC