Hi Stephan,
On Thu, 10 Aug 2017, 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.
...
Changes v8: * port to kernel 4.13 * port to consolidated AF_ALG code Stephan Mueller (4): crypto: AF_ALG -- add sign/verify API crypto: AF_ALG -- add setpubkey setsockopt call crypto: AF_ALG -- add asymmetric cipher crypto: algif_akcipher - enable compilation crypto/Kconfig | 9 + crypto/Makefile | 1 + crypto/af_alg.c | 28 ++- crypto/algif_aead.c | 36 ++-- crypto/algif_akcipher.c | 466 ++++++++++++++++++++++++++++++++++++++++++++ crypto/algif_skcipher.c | 26 ++- include/crypto/if_alg.h | 7 +- include/uapi/linux/if_alg.h | 3 + 8 files changed, 543 insertions(+), 33 deletions(-) create mode 100644 crypto/algif_akcipher.c -- 2.13.4
The last round of reviews for AF_ALG akcipher left off at an impasse around a year ago: the consensus was that hardware key support was needed, but that requirement was in conflict with the "always have a software fallback" rule for the crypto subsystem. For example, a private key securely generated by and stored in a TPM could not be copied out for use by a software algorithm. Has anything come about to resolve this impasse?
There were some patches around to add keyring support by associating a key ID with an akcipher socket, but that approach ran in to a mismatch between the proposed keyring API for the verify operation and the semantics of AF_ALG verify.
AF_ALG is best suited for crypto use cases where a socket is set up once and there are lots of reads and writes to justify the setup cost. With asymmetric crypto, the setup cost is high when you might only use the socket for a brief time to do one verify or encrypt operation.
Given the efficiency and hardware key issues, AF_ALG seems to be mismatched with asymmetric crypto. Have you looked at the proposed keyctl() support for crypto operations?
Thanks, -- Mat Martineau Intel OTC
