Re: [RFC PATCH 0/8] crypto: AF_ALG support for KPP
Am Mittwoch, 19. April 2017, 14:03:35 CEST schrieb Tudor Ambarus: Hi Tudor, > Hi, Stephan, Herbert, > > On 19.04.2017 02:03, Stephan Müller wrote: > > The patch 8 describes the different operations that are supported by > > AF_ALG > > KPP. This support includes generation and retaining of the private key > > inside the kernel. This private key would never be sent to user space. > > There are crypto co-processors that are capable of generating and > retaining the private key inside the device without revealing it to > kernel. The private key will be further used to generate the public > key and the shared secret. Should we extend the KPP API to support this? The less software has access to secrets, the better. Thus, having such API would be good. This of course assumes that the private key is generated with an appropriate RNG. As normal users cannot verify the RNG or the noise sources implemented in hardware, the choice of using such API to keep the private key inside the hardware should be left to the caller. >From the AF_ALG KPP support side, I could imagine that that the algif_kpp code makes use of the hardware support unless the caller objects. Ciao Stephan
Re: [RFC PATCH 0/8] crypto: AF_ALG support for KPP
Hi, Stephan, Herbert, On 19.04.2017 02:03, Stephan Müller wrote: The patch 8 describes the different operations that are supported by AF_ALG KPP. This support includes generation and retaining of the private key inside the kernel. This private key would never be sent to user space. There are crypto co-processors that are capable of generating and retaining the private key inside the device without revealing it to kernel. The private key will be further used to generate the public key and the shared secret. Should we extend the KPP API to support this? Thanks, ta
[RFC PATCH 0/8] crypto: AF_ALG support for KPP
Hi, This is an RFC to discuss whether and how to support access to the KPP kernel crypto API (Diffie-Hellman and EC Diffie-Hellman) by user space. The patch set is only meant for discussion and not for production use. Testing is only performed for the DH part via [1]. The DH testing shows that the DH operation shows the same results as OpenSSL. The patch set includes: - addition of PKCS#3 support for DH to allow domain parameters to be set - extension of the setsockopt and cmsg API - addition of AF_ALG KPP interface where the implementation follows the exact same coding style as currently discussed for the memory management fix patch set for algif_skcipher and algif_aead -- this shall allow the immediate incorporation of patches that replace duplicated code with common service functions. The patch 8 describes the different operations that are supported by AF_ALG KPP. This support includes generation and retaining of the private key inside the kernel. This private key would never be sent to user space. I am aware and in fact supported development of the DH support in the keys subsystem. The question will be raised whether the AF_ALG KPP interface is superfluous in light of the keys DH support. My answer is that AF_ALG KPP is orthogonal to the keys DH support. The keys DH support use case is that the keys are managed inside the kernel and thus has the focus on the key management. Contrary, AF_ALG KPP does not really focus on key management but simply externalizes the DH/ECDH support found in the kernel including hardware acceleration. User space is in full control of the key life cycle. This way, AF_ALG could be used to complement user-space network protocol implementations like TLS or IKE to offload the resource intense DH calculations to accelerators. A full description of the DH testing and how to compare it to OpenSSL is present in [1] with the test/kcapi-main.c tool, function "kpp". [1] https://github.com/smuellerDD/libkcapi/tree/kpp Stephan Mueller (8): crypto: AF_ALG -- add DH keygen / ssgen API crypto: AF_ALG -- add DH param / ECDH curve setsockopt call crypto: AF_ALG - eliminate code duplication crypto: KPP - add API crypto_kpp_set_params crypto: DH - allow params and key to be set independently crypto: DH - add PKCS#3 parameter handling crypto: ecdh - constify key crypto: AF_ALG - add KPP support Documentation/crypto/api-kpp.rst |2 +- crypto/Kconfig | 10 + crypto/Makefile |8 +- crypto/af_alg.c | 17 +- crypto/algif_kpp.c | 1230 ++ crypto/dh.c | 21 +- crypto/dh_helper.c | 53 +- crypto/dhparameter.asn1 |4 + include/crypto/dh.h | 21 +- include/crypto/ecdh.h|2 +- include/crypto/if_alg.h |2 + include/crypto/kpp.h | 28 + include/uapi/linux/if_alg.h |4 + 13 files changed, 1384 insertions(+), 18 deletions(-) create mode 100644 crypto/algif_kpp.c create mode 100644 crypto/dhparameter.asn1 -- 2.9.3
