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

HI,

On 11 August 2017 at 02:48, Mat Martineau
[off-list ref] wrote:

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.

Would that time be shorter when going through the keyctl API?

In any case there will be situations, similar to the lightweight TLS
implementation use case, where this isn't a factor.

Given the efficiency and hardware key issues, AF_ALG seems to be mismatched
with asymmetric crypto.

The hardware key support would obviously be a benefit but it's
orthogonal to this I believe.  That issue is not specific to akcipher
either, there will be hardware-only symmetric keys that can't be used
with current ALG_IF.

The ALG_IF API provides a slightly lower level access to the
algorithms listed in /proc/crypto than the keyctl API and I don't see
the reason that some of those algorithms should not be available.

Best regards