+1 on a longer key.
- m&m Matt Miller < [email protected] > Cisco Systems, Inc. On Apr 7, 2013, at 10:47 PM, Dick Hardt <[email protected]> wrote: > FWIW: I'd strongly prefer a longer key than a different KDF scheme. > > On Apr 7, 2013, at 12:32 PM, "Peck, Michael A" <[email protected]> wrote: > >> I prefer using a KDF, as I think the approach of using a long key >> over-complicates key management by requiring generation and transport of a >> longer key than necessary, and it may also provide a false sense of the >> overall security level. >> >> As previously discussed, the Concat KDF is not appropriate, but there are >> other NIST KDFs that seem acceptable for this key expansion purpose. >> For instance, the "KDF in Counter Mode" in NIST SP 800-108 Section 5.1, with >> the PRF algorithm set to the same HMAC algorithm used in the corresponding >> AEAD algorithm. (i.e. use HMAC-SHA-256 as PRF with AES-128 + HMAC-SHA-256, >> and use HMAC-SHA-512 as PRF with AES-256 + HMAC-SHA-512). >> >> For example, for AES-128 + HMAC-SHA-256, where "key" is an inputted 128-bit >> "master" key: >> Expanded key = HMAC-SHA-256(key, 0x00 0x00 0x00 0x01 | "A128CBC+HS256" | >> 0x00 | 0x00 0x00 0x01 0x00) >> AES key = first 128 bits of expanded key >> HMAC key = second 128 bits of expanded key >> >> If JOSE chooses to use draft-mcgrew-aead-aes-cbc-hmac-sha2, I think it would >> be worth discussing with the draft authors whether they are interested in >> performing the KDF in the AEAD algorithm itself (for example, input a >> 128-bit key into their AEAD_AES_128_CBC_HMAC_SHA_256 and have it be >> responsible for deriving the 128-bit AES key and 128-bit HMAC key). >> >> Mike >> >>> -----Original Message----- >>> From: [email protected] [mailto:[email protected]] On Behalf Of >>> Jim Schaad >>> Sent: Thursday, April 04, 2013 7:51 PM >>> To: [email protected] >>> Subject: Re: [jose] Use of AES-HMAC algorithm - Consensus Request >>> >>> <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 > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
