HI, On 11 August 2017 at 02:48, Mat Martineau <mathew.j.martineau@xxxxxxxxxxxxxxx> 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
