Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann:

Hi Marcel,

quoted

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.

Thanks for the reminder. I have looked at that but I am unsure about whether 
this one covers asym crypto appropriately, too.

The issue is that some hardware may only offer accelerators without a full 
blown RSA siggen/ver logic (that pulls in PKCS or OAEP or others). How do you 
propose to cover raw primitives with keyctl?

Ciao
Stephan