On Tue, 24 May 2016, Stephan Mueller wrote:
Am Dienstag, 24. Mai 2016, 08:19:41 schrieb David Howells:
Hi David,
Stephan Mueller <smueller@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
