pkcs11 — archive

[Wan-Teh Chang <msj@nthpermutation.com>]

On Thu, Aug 8, 2013 at 6:40 PM, Michael StJohns <msj@nthpermutation.com> wrote: > > I'm adding a TLS PRF based mechanism that can only be used for key > derivation. The name is CMK_TLS12_KDF and accepts a label, set of random > values and an optional context per that RFC. > > I figured out that you don't have to provide an output structure to produce > multiple keys - instead do a second (third, fourth etc) derivation from the > produced key stream using one of the trivial kdf functions - > CKM_EXTRACT_KEY_FROM_KEY to break up the key stream. Correct. > I may ask the CCM/GCM author to propose a new mechanism that gets its IVs > from somewhere else. For TLS1.3, I'm thinking that inserting a key > derivation step between the key generation and IV generation step might work > - e.g. derive 4 keys plus an IV subkey. From the IV sub key derive the two > IVs. For TLS 1.3 we can also call the TLS PRF with a new label to generate the IVs. Alternatively, we can define a new AES-GCM mechanism that takes the implicit nonce as a generic secret key. NIST SP 800-38D Section 9.1 seems to recommend that the implicit nonce for AES GCM be kept inside a crypto module: 2. The IV shall be a critical security parameter as defined in FIPS Pub. 140-2 until the authenticated encryption function is invoked with the IV. Prior to this invocation, the IV shall be provided the same protection as other critical security parameters in a module that is validated to the requirements in FIPS Pub. 140-2. Wan-Teh