* key retention service: DH support
@ 2016-05-23 18:57 Stephan Mueller
2016-05-24 7:04 ` David Howells
0 siblings, 1 reply; 10+ messages in thread
From: Stephan Mueller @ 2016-05-23 18:57 UTC (permalink / raw)
To: dhowells; +Cc: keyrings, linux-crypto
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-23 18:57 key retention service: DH support Stephan Mueller
@ 2016-05-24 7:04 ` David Howells
2016-05-24 7:14 ` Stephan Mueller
2016-05-24 7:19 ` David Howells
0 siblings, 2 replies; 10+ messages in thread
From: David Howells @ 2016-05-24 7:04 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, keyrings, linux-crypto, mathew.j.martineau
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 7:04 ` David Howells
@ 2016-05-24 7:14 ` Stephan Mueller
2016-05-24 7:19 ` David Howells
1 sibling, 0 replies; 10+ messages in thread
From: Stephan Mueller @ 2016-05-24 7:14 UTC (permalink / raw)
To: David Howells; +Cc: keyrings, linux-crypto, mathew.j.martineau
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 7:04 ` David Howells
2016-05-24 7:14 ` Stephan Mueller
@ 2016-05-24 7:19 ` David Howells
2016-05-24 7:29 ` Stephan Mueller
1 sibling, 1 reply; 10+ messages in thread
From: David Howells @ 2016-05-24 7:19 UTC (permalink / raw)
To: Stephan Mueller; +Cc: dhowells, keyrings, linux-crypto, mathew.j.martineau
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 7:19 ` David Howells
@ 2016-05-24 7:29 ` Stephan Mueller
2016-05-24 16:22 ` Mat Martineau
2016-05-25 10:58 ` David Howells
0 siblings, 2 replies; 10+ messages in thread
From: Stephan Mueller @ 2016-05-24 7:29 UTC (permalink / raw)
To: David Howells; +Cc: keyrings, linux-crypto, mathew.j.martineau
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 7:29 ` Stephan Mueller
@ 2016-05-24 16:22 ` Mat Martineau
2016-05-24 16:45 ` Stephan Mueller
2016-05-25 10:58 ` David Howells
1 sibling, 1 reply; 10+ messages in thread
From: Mat Martineau @ 2016-05-24 16:22 UTC (permalink / raw)
To: Stephan Mueller; +Cc: David Howells, keyrings, linux-crypto, mathew.j.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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 16:22 ` Mat Martineau
@ 2016-05-24 16:45 ` Stephan Mueller
2016-05-25 10:25 ` Herbert Xu
0 siblings, 1 reply; 10+ messages in thread
From: Stephan Mueller @ 2016-05-24 16:45 UTC (permalink / raw)
To: Mat Martineau, herbert; +Cc: David Howells, keyrings, linux-crypto
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 16:45 ` Stephan Mueller
@ 2016-05-25 10:25 ` Herbert Xu
0 siblings, 0 replies; 10+ messages in thread
From: Herbert Xu @ 2016-05-25 10:25 UTC (permalink / raw)
To: Stephan Mueller; +Cc: Mat Martineau, David Howells, keyrings, linux-crypto
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-24 7:29 ` Stephan Mueller
2016-05-24 16:22 ` Mat Martineau
@ 2016-05-25 10:58 ` David Howells
2016-05-26 17:04 ` Mat Martineau
1 sibling, 1 reply; 10+ messages in thread
From: David Howells @ 2016-05-25 10:58 UTC (permalink / raw)
To: Mat Martineau; +Cc: dhowells, Stephan Mueller, keyrings, linux-crypto
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: key retention service: DH support
2016-05-25 10:58 ` David Howells
@ 2016-05-26 17:04 ` Mat Martineau
0 siblings, 0 replies; 10+ messages in thread
From: Mat Martineau @ 2016-05-26 17:04 UTC (permalink / raw)
To: David Howells; +Cc: Mat Martineau, Stephan Mueller, keyrings, linux-crypto
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2016-05-26 17:05 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-23 18:57 key retention service: DH support Stephan Mueller
2016-05-24 7:04 ` David Howells
2016-05-24 7:14 ` Stephan Mueller
2016-05-24 7:19 ` David Howells
2016-05-24 7:29 ` Stephan Mueller
2016-05-24 16:22 ` Mat Martineau
2016-05-24 16:45 ` Stephan Mueller
2016-05-25 10:25 ` Herbert Xu
2016-05-25 10:58 ` David Howells
2016-05-26 17:04 ` Mat Martineau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.