Hi Stephan, >>> 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? where is such a hardware? And what is the usage of it? Look at what we are using asymmetric crypto for at the moment. It is either for sign and verify with secure boot etc. Or it is for key exchange purposes. The asymmetric crypto is a means to an end. If it is not for certification verification, then it for is creating a symmetric key to be used with a symmetric cipher. We have the the asymmetric_keys subsystem for representing the nature of this crypto. Also the list of asymmetric ciphers is a lot smaller than the symmetric ones. What raw primitives? When we are using for example ECDH for Bluetooth where you need to create a pairwise symmetric key, then what you really want from the cryptographic primitives is this: 1) Create public/private key pair 2) Give public key to applications and store the private key safely 3) Retrieve public key from remote side and challenge 4) Compute key exchange magic (like DH) from remote public key 5) Tell the key generator to throw away the private key So I do not want to load any private key into the kernel. I want the kernel to give me a public key and allow me to feed the key exchange primitive with the remote public key. This is clearly not AF_ALG. We had this discussion during the KPP design and I made it clear multiple times that this is totally different. This is clearly keyctl area of interfaces since the main operation is key generation. I am not saying that keyctl is perfect just yet, but we are working on it. We however have to accept that it is more suitable than AF_ALG. You will never have stream based data feed into an asymmetric cipher. That is what stream ciphers are for. Regards Marcel
