Am Donnerstag, 27. April 2017, 18:55:13 CEST schrieb Marcel Holtmann: Hi Marcel, > 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. ... as well as DH operations :-) I would think that hardware support would fit into the keys DH framework just like it fits seamlessly into the kernel crypto API framework. > > 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. I do not think this argument is correct. The kernel crypto API requires that a key is set with a tfm -- i.e. a tfm is a representation of the "static" parts of a cipher instance (key, AAD-length, others). When you have a tfm that is ready for a cipher operation, all required data like a key must have been set with it. This tfm is now used with a "request" that defines the "volatile" data of the cipher operation. For kpp the kernel crypto API may add one API call to generate a tfm without setting a real key, similar to my KPP AF_ALG proposal I aired a couple of days ago. Tudor's hardware could generate the key internally, whereas other implementations in the kernel could use a logical equivalent as the kpp_genkey function in [1]. I.e. if the key is provided by the caller, it should be taken by the tfm. If no key is provided or a null is provided, the DH implementation should generate the key and retain it with the tfm. That tfm then could be linked to by the keys framework. [1] https://www.spinics.net/lists/linux-crypto/msg25296.html Ciao Stephan PS: Marcel, could you comment on the kpp AF_ALG proposal I sent around some days ago? As DH operations are at the same time crypto operations and pure key management operations, I am not sure whether DH hardware should be externalized with an AF_ALG interface or keys interface. DH is a key management cipher type and thus fits with the keys framework, but AF_ALG provides an async interface. Further, when DH hardware is used to accelerate things like user space TLS / IKE / SSH or whatever, is the keys interface complete (think of scatter-gather-list / IOVEC handling offered by AF_ALG)?
