Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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

[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux