Hi Stephan,

quoted

quoted

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