Hi Mat, >> 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? we have also seen hardware now where the private key will never leave the crypto hardware. They public and private key is only generated for key exchange purposes and later on discarded again. Asymmetric ciphers are really not a good fit for AF_ALG and they should be solely supported via keyctl. Regards Marcel
