Hi Tudor, >> you still need to get the public key out of the kernel if you want to use it from user space. Or feed the remote public key if you plan to use some sort of key derivation function. > > The crypto hardware that I'm working on, generates the private key > internally within the device and never reveals it to software and > immediately returns the public key pair. The user can retrieve the > public key from hardware. and don’t we want some sort of access control here. Only the user / process that requested the private key and has access to the public key is allowed to keep using the private key? >> I am saying this again, if you only have a hammer, everything looks like a nail. What about actually looking at how this would be used from user space in real crypto cases. >> My point is that the usages here are key generation, some sort of key-exchange-agreement (aka DH) and key derivation into a symmetric key. Frankly the focus with asymmetric ciphers are the keys and the key derivation. They are not encryption and decryption of massive amounts of data. > > The hardware uses it's own private key and the public key received from > the other end and computes the ecdh shared secret. The hardware computed > shared secret can then be used for key derivation. And that is normally the case. Get your local public key, send it to the other side, get the other sides public key, give it to the hardware and get shared secret. So how is AF_ALG a good fit here? Regards Marcel
