Re: [jose] Use of AES-HMAC algorithm

[Dick Hardt <[e-mail]>]

Hi Jim

Not being at the meeting, I don't have the background to understand what the issue was in order to interpret your email.

Having implementations that use AES-HMAC, I want to understand.

Any pointers so that I can understand would be greatly appreciated.

-- Dick

On Mar 27, 2013, at 3:20 PM, "Jim Schaad" <[e-mail]> wrote:

> <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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose