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

This sounds to me like yet another argument for (1) removing the integrity
protection from the JOSE header, and (2) creating a separate binary
component in JWE to hold the AAD.

--Richard

On Sun, Mar 17, 2013 at 8:02 PM, Manger, James H <
James.H.Manger@team.telstra.com> wrote:

> >> 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****
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>