On Fri, Aug 11, 2017 at 7:05 PM, Marcel Holtmann <mar...@holtmann.org> wrote: > Hi Stephan, > >>> 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. >> >> To me, the entire AF_ALG purpose is solely to export hardware support to user >> space. That said, if user space wants an accelerator, a socket would be >> opened >> once followed by numerous read/write requests. >> >> Besides, I am aware of Tadeusz' patch to link algif_akcipher to the keyring >> and I planned to port it to the current implementation. But I thought I offer >> a small patch focusing on the externalization of the akcipher API first. >> >> I think the keyctl and AF_ALG are no opponents, but rather are orthogonal to >> each other. The statement I made for the KPP AF_ALG RFC applies here too: >> >> """ >> I am aware and in fact supported development of the DH support in the keys >> subsystem. The question will be raised whether the AF_ALG KPP interface is >> superfluous in light of the keys DH support. My answer is that AF_ALG KPP is >> orthogonal to the keys DH support. The keys DH support use case is that >> the keys are managed inside the kernel and thus has the focus on the >> key management. Contrary, AF_ALG KPP does not really focus on key management >> but simply externalizes the DH/ECDH support found in the kernel including >> hardware acceleration. User space is in full control of the key life cycle. >> This way, AF_ALG could be used to complement user-space network protocol >> implementations like TLS or IKE to offload the resource intense DH >> calculations to accelerators. >> “"" > > we do not need two interfaces for doing the same thing. Especially not one > that can not handle hardware backed keys. And more important if you can not > abstract an accelerator that doesn’t expose the private key at all.
While I don't have anything to contribute to the choice between keyctl() vs ALG_IF as interfaces for asymmetric cryptography, I would like to point out that there is both interest and HW support for private symmetric key operations as well, for example for storage encryption via DM-Crypt and fscrypt, so I do hope (and will work on) adding some sort of HW key support the crypto API, community acceptance withstanding of course. So I hope we won't treat the idea of crypto API lack of support for HW keys as a long standing immutable argument. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker "If you take a class in large-scale robotics, can you end up in a situation where the homework eats your dog?" -- Jean-Baptiste Queru