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
