OK, I admit that the way I phrased my request may not be exactly in line
with the way the “AEAD” terminology is used.
I can correct that. That’s syntax.
I was using “AEAD” as a shorthand for the working group’s decision to
use only authenticated encryption algorithms – not to mean the particular
combined representation of those parameters apparently specified in the AEAD
draft. I will correct the terminology
usage in the next revision of the JOSE specifications.
The semantic point remains that it’s cleaner and more flexible to have
the Key, the Plaintext, IV, and “additional authenticated data” parameters all
be separate inputs and the Ciphertext and “authentication tag” all be separate
outputs. In JOSE’s particular use case,
that would be a significantly better match and easier for implementers to use.
JOSE already has a way of combining the inputs and outputs that’s
inherent to its representation, and it doesn’t match the one you’ve
specified. GCM, CTR, and the current
JOSE-specified algorithms are a great fit for this, as they can directly use
that representation. The AEAD pattern
you cite requires disassembly of the components of the AEAD-specific
representation to be able to use the combinations already present in the JOSE
representations and then reassembly at decryption time. That’s just more work
for implementers, and
it’s not semantically necessary work.
Are you open to specifying versions of your algorithms that don’t require
a particular combination method for the parameters, but instead leave the
combination
up to the use case? I’m fine with you
also specifying a specific combination method as an optional feature of the
specification. But it shouldn’t be part
of the algorithm definition, just like it isn’t for GCM.
Best
wishes, --
Mike
From: David McGrew (mcgrew) [mailto:[email protected]]
Sent: Monday, November 12, 2012 11:43 AM
To: Mike Jones; [email protected]; [email protected]
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
version 01
Hi Mike,
From: Mike Jones <[email protected]>
Date: Monday, November 12, 2012 1:55 PM
To: Cisco Employee <[email protected]>,
"[email protected]" <[email protected]>, "[email protected]" <[email protected]>
Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
version 01
As background, if there was a version of this spec that did
not assume that the parameters would be concatenated together in a specific
way, but left them as independent inputs and outputs, as AES GCM and AES CTR do,
it would be a better match for JOSE’s use case. I believe that what you
are referring to is the inclusion of the authentication tag in the
authenticated ciphertext. This is not just a property of
draft-mcgrew-aead-aes-cbc-hmac-sha2; it is a feature of all 19 of the AEAD
algorithms that have been defined so far. For
comparison, draft-mcgrew-aead-aes-cbc-hmac-sha2 says
The AEAD Ciphertext consists of the string S, with the string T
appended to it. This Ciphertext is returned as the output of the
AEAD encryption operation. Where S is the
ciphertext and T is the authentication tag. RFC 5116 says
"The AEAD_AES_128_GCM ciphertext is
formed by appending
the authentication tag provided as an output to the GCM encryption
operation to the ciphertext that is output by that
operation."
David
-- Mike
From: [email protected]
To: [email protected]; [email protected]
Date: Mon, 12 Nov 2012 18:20:57 +0000
CC: [email protected]
Subject: [jose] Authenticated Encryption with AES-CBC and HMAC-SHA, version
01
Hi,
There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA",
and I would appreciate your review. It is online at
<https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?include_text=1>
The diff between the current and the previous version is available at
<http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01>
This draft has been proposed for use in the JOSE WG
<http://datatracker.ietf.org/wg/jose/> , where its adoption would allow the
working group to omit "raw" unauthenticated encryption, e.g. AES-CBC, and only
include authenticated encryption. Thus I am asking for your help in making
John Foley generated test cases that correspond to the current version of the
draft, but I didn't include these in the draft because I did not yet get
confirmation from a second independent implementation. With hope, there will
not be any need for any normative
changes, and I will include these after I get confirmation.
Thanks,
David
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
