RE: [pkcs11] RE: NIST Special Publication 800-38F

["Burns, Robert" <Robert.Burns@thalesesec.com>]

Mike,

Quite true and I think offering advice on proper nonce selection is important and valuable.

From a specification standpoint though, I think we shouldn't necessarily keep a primitive out just because it might be 'hard' to get right -- we should do our best to help the user and provide them with the maximum information -- as you stated, perhaps we could hide this from them by generating the IV as part of the wrap and return as an output?  Besides, if we were truly concerned with protecting the users from themselves we shouldn't let them use 'C'! ;->

Bob

> -----Original Message-----
> From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org] On
> Behalf Of Michael StJohns
> Sent: Tuesday, April 09, 2013 5:59 PM
> To: pkcs11@lists.oasis-open.org
> Subject: Re: [pkcs11] RE: NIST Special Publication 800-38F
> 
> On 4/3/2013 6:19 PM, Burns, Robert wrote:
> > It would appear that NIST will allow other approved encryption modes, so
> GCM is a candidate.
> Yes.  But it is listed in 2.30 without the wrapping/unwrapping flag (as is CCM).
> I think if we do modify the mechanism to allow wrapping, we probably
> should provide some guidance on IV/Nonce selection (or allow it to be done
> only internally?)  The nice thing about the AES Keywrap algorithm is that the
> output is fully self-contained - you don't need to track an IV or other ancillary
> data separately.
> >
> > In general, I think we should only block inclusions of mechanisms if there
> are known security issues, and I wasn't able to locate any obvious research
> on the subject of the AEAD modes as being weaker for key wrap versus data
> protection.  Anyone know of any prohibitions against using GCM for key
> wrapping?
> I brought this up originally. I *thought* I'd read something suggesting that
> this wasn't an appropriate use of AEAD mechanisms, but I can't find it now.
> That said, I would tend to avoid XOR style key wrap mechanisms because
> they are too easy to get wrong (e.g. duplicate an IV and you can compromise
> a lot of keys) during implementation and use.  The commentary in RFC5297
> section 1.3.2 is somewhat on point.
> 
> Mike
> 
> >
> > Bob
> >
> >> -----Original Message-----
> >> From: pkcs11@lists.oasis-open.org [mailto:pkcs11@lists.oasis-open.org]
> On
> >> Behalf Of Lockhart, Robert
> >> Sent: Wednesday, April 03, 2013 6:01 PM
> >> To: pkcs11@lists.oasis-open.org
> >> Subject: [pkcs11] NIST Special Publication 800-38F
> >>
> >> I took a quick glance and GCM and CCM are in fact only mentioned in the
> >> Appendix B as other authenticating modes of operation.  The major
> >> difference being that GCM & CCM perform authentication on the
> encrypted
> >> value not the clear text value.
> >>
> >> http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-38F.pdf
> >>
> >> This will teach me to re-read the documents before bringing them up.
> >>
> >> Bob L.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe from this mail list, you must leave the OASIS TC that
> >> generates this mail.  Follow this link to all your TCs in OASIS at:
> >> https://www.oasis-
> >> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> > ---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php