Hi Tudor, > I'm working with a crypto accelerator that is capable of generating and > retaining ecc private keys in hardware and further use them for ecdh. > The private keys can not be read from the device. This is good because > the less software has access to secrets, the better. > > Generation and retention of ecc private keys are also helpful in a user > space to kernel ecdh offload. The privkey can be generated in kernel and never revealed to user space. > > I propose to extend the ecc software support to allow the generation of > private keys. ECDH software implementation and drivers will permit the > users to provide NULL keys. In this case, the kernel (or the device, if > possible) will generate the ecc private key and further use it for ecdh. > > What's your feeling on this? can we represent these keys via keyctl as part of the kernel keyring? I think when it comes to asymmetric crypto and its keys, we need to have these as keys represented in kernel keyring. Recently we added keyctl features to sign, verify, encrypt and decrypt operations. The crypto subsystem concept is broken when it comes to keys in hardware since it enforces the concept of always being able to fallback on a software implementation of the algorithm. Regards Marcel
