lkml.org 
[lkml]   [2019]   [Jan]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler
Date
Am Mittwoch, 9. Januar 2019, 01:44:31 CET schrieb James Bottomley:

Hi James,

> Actually, it would be enormously helpful if we could reuse these pieces
> for the TPM as well.

Could you please help me understand whether the KDFs in TPM are directly
usable as a standalone cipher primitive or does it go together with additional
key generation operations?

> It has two KDFs: KDFa, which is the CTR-KDF from
> SP800-108 and KDFe which is the SP800-56A KDF for elliptic curve one
> pass Diffie Hellman, so if we're going to do the former, I'd really
> like the latter as well.
>
> The way the TPM parametrises input to both KDFs is
>
> (hashAlg, key, label, contextU, contextV, bits)
>
> Where
>
> hashAlg = the hash algorithm used as the PRF
> key = the input parameter of variable bit size or
> the x co-ordinate of the shared point
> label = An ASCII string representing the use
> contextU = public input U
> contextV = public input V
> bits = number of output bits

When implementing KDFs as an extension of the kernel crypto API's RNG facility
we currently have to handle the limitiation of the existing API. The label/
context data (and when considering RFC 5869 HKDF requring IKM, salt and
additional information as input) currently cannot directly be communicated
through the API.

The issue is that the RNG facility currently has the following prototype
defined:

int (*generate)(struct crypto_rng *tfm,
const u8 *src, unsigned int slen,
u8 *dst, unsigned int dlen);

The src pointer would need to take the label/context data.

Would it be appropriate, to implement a type cast to a structure from the u8
pointer?

E.g. for the aforementioned label/context data, we could define something like

struct crypto_kdf_ctr {
char *label;
size_t label_len;
u8 *contextU;
size_t contextU_len;
u8 *contextV;
size_t contextV_len;
};

And the implementation of the generate function for CTR KDF would then have a
type cast along the following lines:

if (slen != sizeof(struct crypto_kdf_ctr))
return -EINVAL;
const struct crypto_kdf_ctr *kdf_ctr_input = (struct crypto_kdf_ctr *)src;


For different KDFs, different structs would be needed.

Ciao
Stephan


\
 
 \ /
  Last update: 2019-01-09 07:45    [W:0.464 / U:1.716 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site