While I like the detailed examples of barnes draft. I have to agree, that the explosion of combinations is not good for implementers. It's overwhelming and doesn't foster interop on the open web. Look at XMLEnc and all the options you have, imho that's why standards don't end up being adopted wildly in every language (only some of those algos end up being implemented in each language creating an interop nightmare). Jones draft is simple enough (although it would be good to add some examples).
On Thu, Jun 27, 2013 at 1:48 PM, Jim Schaad <[email protected]> wrote: > James, > > The small devices use case does present a reason for wanting to use > AES-GCM rather than AESKW for this case. Specifically, there is no need to > have silicon devoted to doing AES decrypt. All operations can be done just > with AES encrypt. > > jim > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Manger, James H > > Sent: Wednesday, June 26, 2013 7:40 PM > > To: [email protected] > > Subject: Re: [jose] Issue #13 - use AES-GCM for Key Wrapping > > > > I don't think we should standardize > draft-jones-jose-aes-gcm-key-wrap-00. No > > rationale is apparent. We already have an AES-based key wrap algorithm > > (A128KW, A256KW), which has a 64-bit size overhead. The AES-GCM key > > wrap algorithm in this draft add almost no useful properties, but has a > 224-bit > > size overhead. > > > > I like the concatenation of the IV, ciphertext, and tag byte arrays. But > doing > > this here while content encryption serializes the same values as > dot-separated > > B64 blobs does smell of poor ad hoc design. It is nice to highlight how a > > previous choice complicates extending JOSE to other algorithms, but only > if > > we then fix that previous choice. > > > > If the additional authenticated data (AAD) was used to bind the CEK > algorithm > > id (or other context info, as ConcatKDF does) to the wrapped key, then > there > > would at least be an extra security property that would make this key > wrap > > algorithm worth considering. For instance, instead of AAD being empty, > AAD > > could be the "key wrap: " + "enc" value. > > > > By reusing a CEK algorithm as a KEK algorithm, and supporting direct > > encryption, we substantially increase the risk that an attacker can > rearrange > > some encrypted content so a legitimate recipient treats it as an > encrypted key > > leading to security flaws. > > > > For example, Alice sends "Start of PIN = 8" confidentially to Bob: > > {alg:dir,enc:A128GCM,kid:1}..iv.ciphertext.tag > > An attacker seeing this JOSE message learns nothing about the 1st digit > of the > > PIN. > > But if the attacker sends 10 messages to Bob for 10 guess of that digit: > > > > {alg:A128GCMKW,enc:A128GCM,kid:1}.iv|ciphertext|tag.ivN.ciphertextN.tag > > N > > where ivN.ciphertextN.tagN are calculated using an AES key of "Start of > PIN = > > <N>", then 9 messages will cause errors, while 1 message will be > accepted -- > > revealing the supposedly confidential information in 10 guesses instead > of > > 2^128. > > > > Actually the above attack does not quite work for the compact encoding as > > AAD is never empty for content encryption. I not certain for the JSON > > encoding. In any case, an explicit and unambiguous AAD value for key > > wrapping would be good. > > > > Finally, a key wrap algorithm like this should go to the IETF crypto > group > > (CRFG) instead of being invented in JOSE. We have already spent a year > > unpicking a JOSE-special AEAD algorithm. > > > > -- > > James Manger > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On Behalf > > > Of Jim Schaad > > > Sent: Wednesday, 26 June 2013 2:53 AM > > > To: [email protected] > > > Subject: [jose] Issue #13 - use AES-GCM for Key Wrapping > > > > > > We now have two documents one from Richard and one from Mike which > > > provide the two different ways that have been proposed for doing key > > > wrapping with an AEAD algorithm. > > > > > > Please review the two documents and provide comments to the list. > > > > > > Jim > > > > _______________________________________________ > > jose mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
