+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
--
James Manger
From: [email protected] [mailto:[email protected]] On Behalf Of David
McGrew (mcgrew)
Sent: Tuesday, 13 November 2012 10:20 AM
To: Michael Jones; [email protected]; [email protected]
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.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
