Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

["David McGrew (mcgrew)" <[e-mail]>]

Hi James,

From: <Manger>, James H <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, November 13, 2012 1:33 AM
To: Cisco Employee <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

+10

This is much clearer, and much more suitable for separating what goes in a JOSE library vs what goes in a general-purpose crypto library. Even if a JOSE library needs to implement parts of the crypto today because native AEAD support is not yet present, this solution makes it much more likely JOSE will be compatible with native AEAD as it becomes available. I think it is unlikely that native AEAD support (once available) would support both JOSE and draft-mcgrew variants of AEAD-from-AES-CBC-HMAC. The draft-mcgrew variant has a better chance of being implemented because it doesn’t impose a 33% performance penalty for the MACing part, and the other differences are trivial.

The fact that some existing AEAD algorithms (SIV [RFC 5297]) don’t produce a separate authentication tag is a clear indication that a single ciphertext output is a better general model for AEAD in JOSE than separate ciphertext and integrity values as in JWE today.

Editorials:
“JWE Initialization Vector” should be renamed “JWE Nonce”.
The nonce paragraph needn’t hardwire 2 lengths (0 and 96 bits) – leave it to each alg to specify.
The table can include key and nonce sizes.
    "enc"                key size    nonce size  Algorithm
    -----------------------------------------------------------------------
    "A128GCM"   16 bytes    12 bytes     AEAD_AES_128_GCM
    "A256GCM"   32 bytes    12 bytes     AEAD_AES_256_GCM
     "A128CHS"     48 bytes     0 bytes      AEAD_AES_128_CBC_HMAC_SHA_256
     "A256CHS"     64 bytes     0 bytes      AEAD_AES_256_CBC_HMAC_SHA_512

Thanks for the good suggestions (agreed on all of them) and support.

Regards,

David


--
James Manger

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of David McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Cfrg] [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

…
I am not dogmatically opposed to other interfaces, but the best solution here is for JOSE to actually use the 5116 interface, like this:

X.Y. Authenticated Encryption

   This section defines the specifics of encrypting the JWE Plaintext
   Using the Authenticated Encryption with Associated Data (AEAD)
   as defined in RFC 5116.   The authenticated encryption operation
   has four inputs, as follows:

     The secret key is the CMK.

     The associated data is the bytes of the ASCII representation of the concatenation of
     the Encoded JWE Header, a period ('.') character, the Encoded JWE
     Encrypted Key, a second period character ('.'), and the Encoded JWE
     Initialization Vector, per Section 5 of the JWE specification.

      The plaintext , which contains the data to be encrypted and
      authenticated.

      A nonce N, with a length of either 0 or 96 bits.   If the length
      is zero, the nonce is omitted.  Otherwise, the nonce
      is as described in Section 3 of RFC 5116.

   There is a single output, the Ciphertext.

   The "enc" header  parameter values are set as follows:

    "enc"                  Algorithm
    -----------------------------------------------------------------------
    "A128GCM"     AEAD_AES_128_GCM
    "A256GCM"     AEAD_AES_256_GCM
     "A128CHS"      AEAD_AES_128_CBC_HMAC_SHA_256
     "A256CHS"      AEAD_AES_256_CBC_HMAC_SHA_512
      "A128SIV"      AEAD_AES_SIV_CMAC_256
      "A256SIV"      AEAD_AES_SIV_CMAC_384

      See <http://www.iana.org/assignments/aead-parameters/aead-parameters.xml><http://www.iana.org/assignments/aead-parameters/aead-parameters.xml%3e> for the
     references corresponding to these symbolic names.