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

On Wed, Aug 22, 2012 at 6:43 PM, Wan-Teh Chang <wtc@google.com> 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
mode.

That's why I think for symmetric keys, the block (and padding) must be
part of the tainting for a Key.

>
> 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
believe.

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 Thursday, 23 August 2012 02:00:24 UTC