On Fri, Aug 11, 2017 at 7:05 PM, Marcel Holtmann <marcel@xxxxxxxxxxxx> 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
