Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

["Manger, James H" <[e-mail]>]

>> For instance, JWE includes the IV as part of the additional authenticated data (AAD). No other AEAD system is defined like this. Everywhere else the IV/nonce and AAD are separate. I hope that doesn’t adversely affect the crypto properties, but it does raise questions about whether it is important for some crypto reason.

[JLS] For this algorithm it is absolutely vital that the IV be protected.  Since the authentication is computed on the post encrypted text not the pre-encyrpted text, a decryption could never be able to correctly determine that the IV passed in was correct if it is not validated!!!!!!


Jim,

A256CBC+HS512 needs to integrity-protect the IV. I am not disagreeing with that.

Every other AEAD algorithm accepts an IV and AAD as separate inputs and *internally to the AEAD algorithm* ensures the appropriate integrity protection is applied. This is what GCM, CCM, and SIV do. It is the what RFC5116 (AEAD interface) assumes. It is what any crypto library with an explicit AEAD interface will support (separate calls or separate parameters for the IV and AAD).

JWE defines the AAD to be the Header+WrappedKey+IV. That is, the IV is included in the AAD.

Consequently every other AEAD algorithm (such as A128GCM) will process the JWE IV twice. In A128GCM, for example, the IV will be passed from JOSE code to an underlying crypto API once as a 12-byte (96-bit) binary value, and also as 16 base64url characters at the end of the AAD. For all these AEAD algorithms this duplication is merely slightly wasteful, but I guess (hope) it has no impact on security.

The JOSE-specific A256CBC+HS512 algorithm, in contrast, is different. This algorithm would be insecure if the AAD did not include the IV. What would happen if A256CBC+HS512 was implemented in a crypto library accessed via a generic AEAD interface? Perhaps it would have to base64url-encode the IV it was passed and check that it matches the end of the AAD it was passed (making it unsuitable as a generic AEAD alg in any other context)?

--
James Manger