Hi Tudor -
On Mon, 2 Oct 2017, Tudor Ambarus wrote:
Hi, all,
On 08/10/2017 09:39 AM, Stephan Müller wrote:
Hi,
This patch set adds the AF_ALG user space API to externalize the
asymmetric cipher API recently added to the kernel crypto API.
Do we have enough pros and cons so we can decide which interface to use
for exporting akcipher/kpp to user-space?
I'm willing to invest some time to make this happen.
David Howells has a branch implementing asymmetric crypto operations using
keyctl:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=keys-asym-keyctl
That's based on v4.8-rc1, but I've been merging it with more recent
kernels, and it's been working fine:
https://git.kernel.org/pub/scm/linux/kernel/git/martineau/linux.git/log/?h=ell-key-crypto
As far as I know, these keyctl operations are not upstream yet because
there isn't yet a hardware (TPM) asymmetric key subtype that would allow
the key subsystem to choose between akcipher or TPM crypto depending on
the key subtype in use.
I'd like to see the functionality merged even with only akcipher support.
The only issue I've had with the existing patch set is that RSA
verification can't unpad certain results before comparing because the
necessary functionality was removed from rsa-pkcs1pad in the kernel. This
isn't a limitation of the keyctl patch set, though.
A handful of the people on this thread had agreed to move ahead with the
keyctl API because it could handle key material well and choose between
crypto engines (including engines that did not support software fallback)
- that's when David put together his patches. David, is there help you
could use with the hardware asymmetric key subtype or other aspects of
keyctl crypto?
--
Mat Martineau
Intel OTC
