key retention service: DH support

key retention service: DH support

[Stephan Mueller]

Hi David,

With the new DH support for the key retention service, support for DH derived 
keys pops up.

The implementation in security/keys/dh.c returns the DH shared secret straight 
to the user space caller.

I implemented a KDF with that exact scenario already in mind: [1].

I am wondering whether the shared secret should be processed by a KDF before 
returning the data to user space?

[1] http://www.chronox.de/kdf.html

Ciao
Stephan

Re: key retention service: DH support

[David Howells]

Stephan Mueller <smueller@chronox.de> wrote:

> With the new DH support for the key retention service, support for DH derived 
> keys pops up.
> 
> The implementation in security/keys/dh.c returns the DH shared secret straight 
> to the user space caller.
> 
> I implemented a KDF with that exact scenario already in mind: [1].
> 
> I am wondering whether the shared secret should be processed by a KDF before 
> returning the data to user space?
> 
> [1] http://www.chronox.de/kdf.html

Adding Mat to the cc list.  If we want to modify the new DH keyctl, we have a
very short time window in which to do so.

David

Re: key retention service: DH support

[Stephan Mueller]

Am Dienstag, 24. Mai 2016, 08:04:28 schrieb David Howells:

Hi David,

> Stephan Mueller <smueller@chronox.de> wrote:
> > With the new DH support for the key retention service, support for DH
> > derived keys pops up.
> > 
> > The implementation in security/keys/dh.c returns the DH shared secret
> > straight to the user space caller.
> > 
> > I implemented a KDF with that exact scenario already in mind: [1].
> > 
> > I am wondering whether the shared secret should be processed by a KDF
> > before returning the data to user space?
> > 
> > [1] http://www.chronox.de/kdf.html
> 
> Adding Mat to the cc list.  If we want to modify the new DH keyctl, we have
> a very short time window in which to do so.

The KDF patches are fully tested. All that would be needed on the key 
retention side after the shared secret generation are the following calls:

kdf = crypto_alloc_rng(NAME, 0, 0);

crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));

crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);

NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"

LABEL would be an arbitrary string defined by the key service (e.g. 
"LxKeyRet").

Ciao
Stephan

Re: key retention service: DH support

[David Howells]

Stephan Mueller <smueller@chronox.de> wrote:

> The KDF patches are fully tested. All that would be needed on the key 
> retention side after the shared secret generation are the following calls:
> 
> kdf = crypto_alloc_rng(NAME, 0, 0);
> 
> crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
> 
> crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
> 
> NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
> 
> LABEL would be an arbitrary string defined by the key service (e.g. 
> "LxKeyRet").

So there wouldn't be a change to the DH keyctl (including functional)?

David

Re: key retention service: DH support

[Stephan Mueller]

Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells:

Hi David,

> Stephan Mueller <smueller@chronox.de> wrote:
> > The KDF patches are fully tested. All that would be needed on the key
> > retention side after the shared secret generation are the following calls:
> > 
> > kdf = crypto_alloc_rng(NAME, 0, 0);
> > 
> > crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
> > 
> > crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
> > 
> > NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
> > 
> > LABEL would be an arbitrary string defined by the key service (e.g.
> > "LxKeyRet").
> 
> So there wouldn't be a change to the DH keyctl (including functional)?

Assuming that the LABEL and/or the KDF name are not configurable by user 
space, the only potential difference I would see is that a user could ask for 
the length of the output data.

Think of it like the KDF in a network protocol where the shared secret has 
some length X but the caller needs data of length Y for a specific use (e.g. a 
symmetric key plus an HMAC key). The use case for such "local" DH operation 
would be the writing of encrypted data while the system is locked. The 
encryption of the actual file data is done using a symmetric algo with 
symmetric key, potentially with an integrity key. Usually, the DH shared 
secret size is not equal to the size of a symmetric key. So, a KDF would be 
needed to bring it to the right size.

Ciao
Stephan

Re: key retention service: DH support

[Mat Martineau]

On Tue, 24 May 2016, Stephan Mueller wrote:

> Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells:
>
> Hi David,
>
>> Stephan Mueller <smueller@chronox.de> wrote:
>>> The KDF patches are fully tested. All that would be needed on the key
>>> retention side after the shared secret generation are the following calls:
>>>
>>> kdf = crypto_alloc_rng(NAME, 0, 0);
>>>
>>> crypto_rng_reset(kdf, <shared_secret>, sizeof(<shared_secret>));
>>>
>>> crypto_rng_generate(kdf, LABEL, sizeof(LABEL), outbuf, outbuflen);
>>>
>>> NAME would be the KDF type such as "kdf_ctr(hmac(sha256))"
>>>
>>> LABEL would be an arbitrary string defined by the key service (e.g.
>>> "LxKeyRet").
>>
>> So there wouldn't be a change to the DH keyctl (including functional)?
>
> Assuming that the LABEL and/or the KDF name are not configurable by user
> space, the only potential difference I would see is that a user could ask for
> the length of the output data.

KDF transformations would be extremely useful, but transforming the DH 
output using a KDF needs to be configurable. There are enough different 
uses for DH that it's important to have access to the raw values.

Since the KDF patches are not yet merged, I'm not sure of the best way to 
accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by 
adding a 5th arg, an optional pointer to KDF configuration (NAME and 
LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.

--
Mat Martineau
Intel OTC

Re: key retention service: DH support

[Stephan Mueller]

Am Dienstag, 24. Mai 2016, 09:22:22 schrieb Mat Martineau:

Hi Mat, Herbert
> 
> KDF transformations would be extremely useful, but transforming the DH
> output using a KDF needs to be configurable. There are enough different
> uses for DH that it's important to have access to the raw values.
> 
> Since the KDF patches are not yet merged, I'm not sure of the best way to
> accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> adding a 5th arg, an optional pointer to KDF configuration (NAME and
> LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.

With that statement, Herbert, should we start looking into my KDF patches 
after the merge window closes?

Ciao
Stephan

Re: key retention service: DH support

[Herbert Xu]

On Tue, May 24, 2016 at 06:45:09PM +0200, Stephan Mueller wrote:
> Am Dienstag, 24. Mai 2016, 09:22:22 schrieb Mat Martineau:
> 
> Hi Mat, Herbert
> > 
> > KDF transformations would be extremely useful, but transforming the DH
> > output using a KDF needs to be configurable. There are enough different
> > uses for DH that it's important to have access to the raw values.
> > 
> > Since the KDF patches are not yet merged, I'm not sure of the best way to
> > accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> > adding a 5th arg, an optional pointer to KDF configuration (NAME and
> > LABEL). Or a separate KEYCTL_DH_COMPUTE_KDF command can be added later.
> 
> With that statement, Herbert, should we start looking into my KDF patches 
> after the merge window closes?

Sure.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: key retention service: DH support

[David Howells]

Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:

> Since the KDF patches are not yet merged, I'm not sure of the best way to
> accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
> adding a 5th arg, an optional pointer to KDF configuration (NAME and
> LABEL).

If we want to do this, it needs to be done before the merge window closes,
maybe by -rc2.  Just requiring the extra argument to be 0 for now and/or
extending struct keyctl_dh_params to include some must-be-zeroed spare space
would do for now.

David

Re: key retention service: DH support

[Mat Martineau]

On Wed, 25 May 2016, David Howells wrote:

> Mat Martineau <mathew.j.martineau@linux.intel.com> wrote:
>
>> Since the KDF patches are not yet merged, I'm not sure of the best way to
>> accomodate the future feature. We could future-proof KEYCTL_DH_COMPUTE by
>> adding a 5th arg, an optional pointer to KDF configuration (NAME and
>> LABEL).
>
> If we want to do this, it needs to be done before the merge window closes,
> maybe by -rc2.  Just requiring the extra argument to be 0 for now and/or
> extending struct keyctl_dh_params to include some must-be-zeroed spare space
> would do for now.

I sent a patch ([PATCH] KEYS: Add optional key derivation parameters for 
DH) to define the additional parameter. For now, an error is returned if 
KDF configuration is provided.

--
Mat Martineau
Intel OTC