Re: crypto-ISSUE-29 (block modes): Handling of block encryption modes and padding [Web Cryptography API]

On Wed, Aug 22, 2012 at 2:22 PM, Web Cryptography Working Group Issue
Tracker <sysbot+tracker@w3.org> wrote:
> crypto-ISSUE-29 (block modes): Handling of block encryption modes and padding [Web Cryptography API]
>
> http://www.w3.org/2012/webcrypto/track/issues/29
>
> Raised by: Ryan Sleevi
> On product: Web Cryptography API
>
> Currently, the Web Cryptography API defines "AES-CTR", "AES-CBC", and "AES-GCM" as unique algorithms. However, functionally, it's a single algorithm (AES), being combined with a single mode of operation (CTR, CBC, GCM), and possibly with different padding requirements (PKCS#7, ANSI X9.23, Zeros, etc)
>
> It may thus be desirable to define a single algorithm (AES), and have it take 'mode' as part of the parameters, along with any mode-specific parameters (eg: IV, counter size).

Arguments in favor:
 - Modes are independent of the block cipher. If we wanted to support
other block ciphers, they could re-use the existing modes.
 - It matches existing JS crypto APIs (eg:
http://code.google.com/p/crypto-js/#Ciphers )

Arguments against:
 - It's not clear what other block ciphers are desirable, nor is it
likely to support a new one in the next 1-4 years.
 - Representing what modes a given key supports is challenging. Using
the same key in different modes is quite dangerous to the
crypto-security. Exposing it as different algorithms helps keep the
concept of "key tainting" clear, where a key can only be used with a
particular algorithm.

Received on Wednesday, 22 August 2012 21:42:18 UTC