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

On 8/22/12 9:59 PM, "Ryan Sleevi" <> wrote:

>On Wed, Aug 22, 2012 at 6:43 PM, Wan-Teh Chang <> wrote:
>> The Algorithm for a Key and the Algorithm for a CryptoOperation
>> probably should be allowed to differ.
>> For example, we may want an AES key whose algorithm is simply "AES",
>> and only specify the mode of operation (CBC, CTR, or GCM) in the
>> algorithm of a CryptoOperation.  Whether the mode of operation is
>> specified as part of the algorithm name or as an algorithm parameter
>> doesn't matter to me.
>I'd disagree here. I think the Key should indicate both it's
>functional type (eg: AES) as well as any part of its 'tainted' type
>(such as the block mode of operation). A key that has been used for
>AES-CBC should not be used with AES-CTR, since the intermingling of
>modes with the same key undermines the security properties of either
>That's why I think for symmetric keys, the block (and padding) must be
>part of the tainting for a Key.


It is extremely bad practice to allow a block cipher key to be used with
multiple modes of operations.

>> As another example, the hash algorithm used in a signature doesn't
>> seem to be a parameter of a Key algorithm, but must be a parameter of
>> the CryptoOperation algorithm. An ECDSA P-256 key should be able to
>> generate signatures with SHA-256 and SHA-512/256.
>This is a bug caused by copying and pasting from RSAES-PKCS1-v1_5
> For key generation for RSASSA-PKCS1-v1_5, RSA-PSS, and RSA-OAEP, the
>key generation parameters were intended to be the combination of the
>(RsaSsaParams, RsaPssParams, RsaOaepParams) and the (RsaKeyGenParams).
>The alternative would be to leave them all as RsaKeyGenParams, and
>simply highlight tainting, which would have the same end-result, I
>This is because, while it is mathematically possible, it is strongly
>discouraged to support multiple hash algorithms with a single key.
>For example, as highlighted in Section 7.1 of RFC 3447, which
>describes RSAES-OAEP, "RSAES-OAEP is  parameterized by the choice of
>hash function and mask generation function. This choice should be
>fixed for a given RSA key". Similar security considerations are
>highlighted in Section 8.1 of RFC 3447.
>I seem to recall similar language in X9.62, specifying ECDSA.
>This means that the choice of hash algorithm SHOULD be part of the key
>'tainting', much like the overall choice of algorithm is.



>We could leave it entirely up to applications, and let themselves run
>the risk of the security issues. I'm not sure whether it significantly
>reduces the implementation load, but it does seem to substantially
>increase the security overhead that consumers of this API would need
>to consider.
>> So, Key algorithms and CryptoOperation algorithms probably should be
>> drawn from two different name spaces.
>> Wan-Teh

Received on Friday, 24 August 2012 17:19:05 UTC