Re: key retention service: DH support

2016-05-26 Thread Mat Martineau
On Wed, 25 May 2016, David Howells wrote: Mat Martineau 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

Re: key retention service: DH support

2016-05-25 Thread David Howells
Mat Martineau 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

Re: key retention service: DH support

2016-05-25 Thread 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 differ

Re: key retention service: DH support

2016-05-24 Thread 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. > >

Re: key retention service: DH support

2016-05-24 Thread 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 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 = cr

Re: key retention service: DH support

2016-05-24 Thread Stephan Mueller
Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells: Hi David, > Stephan Mueller 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); > >

Re: key retention service: DH support

2016-05-24 Thread David Howells
Stephan Mueller 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, , sizeof()); > > crypto_rng_generate(kdf, LABEL, sizeof

Re: key retention service: DH support

2016-05-24 Thread Stephan Mueller
Am Dienstag, 24. Mai 2016, 08:04:28 schrieb David Howells: Hi David, > Stephan Mueller 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 use

Re: key retention service: DH support

2016-05-24 Thread David Howells
Stephan Mueller 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