Having already implemented the KDF in the spec, I have a minor preference to keep it how it is, but no animals will need to be sacrificed if I have to change. On Apr 4, 2013, at 4:51 PM, "Jim Schaad" <[email protected]> wrote:
> <chair> > > At the request of the editors, this is a formal consensus call on the first > item in the list below. If there are objects to use a single long key > rather than a KDF function for the AES-CBC/HMAC algorithm please speak up > now. To date nobody has said that I was wrong to assume the consensus on > that item. > > Call ends in one week. > > Jim > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] On Behalf Of > Jim >> Schaad >> Sent: Wednesday, March 27, 2013 3:21 PM >> To: [email protected] >> Subject: [jose] Use of AES-HMAC algorithm >> >> <chair> >> After spending time looking at and thinking about how to resolve this > issue >> since I was unable to do so at the last F2F meeting. I have come up with > the >> following set of issues that might need to be addressed as part of > resolving >> this issue. >> >> 1. Do we change from using KDC to having a double size key for the >> algorithm? I think that there is probably a consensus that this should be > done. >> >> 2. Should IVs be prepended to the encrypted body as part of the encoding >> steps? If so then this change should be universal. >> >> Doing so would eliminate one field from all of the encoding formats which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for > all >> algorithms as the IV would no longer be a separate item. >> >> 3. Should Authentication Tags be appended to the encrypted body as part of >> the encoding steps? >> >> Doing so would eliminate one field from all of the encoding formats which >> should be considered a plus. >> Doing so would force code writers to understand how large the IV is for > all >> algorithms as the IV would no longer be a separate item. >> Doing so would force a re-organization for the multiple recipient case as >> either all recipient specific data would need to be excluded from the >> authentication step or all of the recipient data would need to be included > for >> by all recipients. >> Changing how the recipient info is process is going to give a performance >> benefit for sending encrypted items for multiple recipients. >> The current strategy of a single IV and key pair with AES-GCM and > different >> authentication data needs to have CFRG look at it. I am worried that it > might >> be a serious security flaw. >> >> 4. Should we reference the McGrew draft and provide text on how things are >> changed or should we "copy" the draft into our text? >> >> 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, >> does this change how we think about any of the above questions? >> >> Allowing for AES-GCM for key wrapping has a benefit for hardware > situations >> as only the encrypt and not the decrypt functions need to be placed in >> hardware. However allowing for this key wrapping give a problem as there > is >> no way to encode the three fields into the encrypted value unless with use >> either a JSON structure in this location or we do use the single appended >> binary output stream. The first approach leads to an expansion of the > field by >> double base64 encoding which is highly undesirable. >> >> 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
