Am Freitag, 11. August 2017, 07:13:30 CEST schrieb Marcel Holtmann: Hi Marcel, > > > > 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
