OASIS PKCS 11 TC

 View Only

  • 1.  NIST Special Publication 800-38F

    Posted 04-03-2013 22:00
    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.


  • 2.  RE: NIST Special Publication 800-38F

    Posted 04-03-2013 22:18
    Although the AEAD mechanisms are not specifically referenced, Section 3.1 of that publication asserts, "Nevertheless, there is no requirement to protect cryptographic keys with a distinct cryptographic method. Previously approved authenticated-encryption modes-as well as combinations of an approved encryption mode with an approved authentication method-are approved for the protection of cryptographic keys, in addition to general data.". It would appear that NIST will allow other approved encryption modes, so GCM is a candidate. 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? Bob >
    Original Message


  • 3.  Re: [pkcs11] RE: NIST Special Publication 800-38F

    Posted 04-03-2013 23:36
    Actually, even blocking mechanisms with known security issues is a problem for things like CIFS that require MD4. Valerie On 04/ 3/13 03:19 PM, Burns, Robert wrote: Although the AEAD mechanisms are not specifically referenced, Section 3.1 of that publication asserts, "Nevertheless, there is no requirement to protect cryptographic keys with a distinct cryptographic method. Previously approved authenticated-encryption modes-as well as combinations of an approved encryption mode with an approved authentication method-are approved for the protection of cryptographic keys, in addition to general data.". It would appear that NIST will allow other approved encryption modes, so GCM is a candidate. 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? Bob
    Original Message


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

    Posted 04-04-2013 14:23
    Quite right, we will always have legacy support issues surrounding existing mechanisms now shown to be flawed. I guess my statement was directed more towards consideration of new mechanisms and functionality, but even then I guess my recommendation should be taken as more of a guideline rather than a rule? Either way, point taken. And in this case I think AEAD for key wrapping should be an acceptable mechanism choice. Thanks, Bob >
    Original Message


  • 5.  Re: [pkcs11] RE: NIST Special Publication 800-38F

    Posted 04-09-2013 21:59
    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


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

    Posted 04-09-2013 22:23
    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


  • 7.  Re: [pkcs11] NIST Special Publication 800-38F

    Posted 04-04-2013 02:25
    On 4/3/2013 6:01 PM, Lockhart, Robert wrote: The major difference being that GCM & CCM perform authentication on the encrypted value not the clear text value. Half-right The MAC for CCM is calculated on the clear text value. You have to decrypt the ciphertext before you can verify the plain text. In GCM you have to generate at least the encryption of the first counter block to do the verification of the cipher text. Although you *could* separate the functions, in practice you do the MAC calculations in lock step with the encryption/decryption. Mike


Related Content