+1
2013/6/28 Matias Woloski <[email protected]> > 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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
