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
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
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
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.
>
>
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
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);
> >
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
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
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