Support for ECDH P-192 and P-256

Hello, we are looking at adding support for Bluetooth Secure Connections to the Security Manager of the Bluetooth subsystem. For that we would need support for ECDH P-256 and eventually also P-192. Right now we are bit lost on how this could be achieved best. I saw that the symmetric_keys

Re: [PATCH RFC 0/6] LLVMLinux: Patches to enable the kernel to be compiled with clang/LLVM

Hi Behan, These patches remove the use of Variable Length Arrays In Structs (VLAIS) in crypto related code. Presented here for comments as a whole (since they all do the same thing in the same way). Once everyone is happy I will submit them individually to their appropriate maintainers.

Using separate initcall level for crypto subsystem

Hi, we wanted to add some crypto selftests to the Bluetooth subsystem that checks our usage of the crypto handling we use for Bluetooth Low Energy Legacy Pairing and Secure Connections. Since the Crypto subsystem and Bluetooth subsystem both use subsys_initcall that goes horrible wrong when

Re: Using separate initcall level for crypto subsystem

Hi Herbert, we can easily run them later on. However when the Bluetooth subsystem is built as module, then I would prefer to have the module loading fail in case one of the selftest fails. I can hack around this with a lot of ifdef config magic. If we would have all crypto, cipher etc.

Limited usefulness of RSA set key function

Hi Tadeusz, I have been working with the AF_ALG patches for akcipher lately and I find the RSA set key function way too limited. Especially the fact that it uses a format that I can not find a single reference / standard for worries me. RsaKey ::= SEQUENCE { n INTEGER ({ rsa_get_n }),

Re: Proposal for adding setpubkey callback to akcipher_alg

Hi Herbert, We already have an interface that can handle asymmetric keys and it is easy to extend with new key formats and key types. So lets use that. I can clearly see that after RSA, we get DSA, ECDH etc. So having a simple way to handle these key formats is a good idea. That

Re: Proposal for adding setpubkey callback to akcipher_alg

Hi Stephan, I think we need to split the akcipher_alg setkey callback into a setkey and setpubkey. diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h index 69d163e39101..ca93952b6d19 100644 --- a/include/crypto/akcipher.h +++ b/include/crypto/akcipher.h @@ -91,6 +91,8 @@

Re: Proposal for adding setpubkey callback to akcipher_alg

Hi Stephan, I think we need to split the akcipher_alg setkey callback into a setkey and setpubkey. diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h index 69d163e39101..ca93952b6d19 100644 --- a/include/crypto/akcipher.h +++ b/include/crypto/akcipher.h @@ -91,6 +91,8 @@

Re: Limited usefulness of RSA set key function

Hi Stephan, It does not. The RSA Private Key has a different format. RSAPrivateKey ::= SEQUENCE { version Version, modulus INTEGER, -- n publicExponentINTEGER, -- e privateExponent INTEGER, -- d prime1

Re: Limited usefulness of RSA set key function

Hi Stephan, I have been working with the AF_ALG patches for akcipher lately and I find the RSA set key function way too limited. Especially the fact that it uses a format that I can not find a single reference / standard for worries me. RsaKey ::= SEQUENCE { n INTEGER ({ rsa_get_n

Proposal for adding setpubkey callback to akcipher_alg

Hi Tadeusz, I think we need to split the akcipher_alg setkey callback into a setkey and setpubkey. diff --git a/include/crypto/akcipher.h b/include/crypto/akcipher.h index 69d163e39101..ca93952b6d19 100644 --- a/include/crypto/akcipher.h +++ b/include/crypto/akcipher.h @@ -91,6 +91,8 @@ struct

Re: Limited usefulness of RSA set key function

Hi Tadeusz, I already have patches for that actually. The question is just which approach to take? My current proposal is to separate the current crypto_akcipher_setkey into two functions. Use the crypto_akcipher_setkey for loading combined private and public key formats and

Re: Limited usefulness of RSA set key function

Hi Tadeusz, as you can clearly see. There are two formats defined here. There is no single ASN.1 structure that can decode both of these. It is what it is, RSA Public Key and RSA Private Key formats are two different key formats. And OpenSSL also treats it like this. You can extract the

Re: Limited usefulness of RSA set key function

Hi Tadeusz, as you can clearly see. There are two formats defined here. There is no single ASN.1 structure that can decode both of these. It is what it is, RSA Public Key and RSA Private Key formats are two different key formats. And OpenSSL also treats it like this. You can extract the

Re: Proposal for adding setpubkey callback to akcipher_alg

Hi Herbert, RSA Private Key is n + e + d (including 6 other fields). RSA Public Key is n + e (no other fields). So for RSA you would make setkey to take RSA Private Key and setpubkey to take RSA Public Key. Meaning you only have to use one of them since if you have the private key, you

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

Hi Stephan, > This patch set adds the AF_ALG user space API to externalize the > asymmetric cipher API recently added to the kernel crypto API. > > The patch set is tested with the user space library of libkcapi [1]. > Use [1] test/test.sh for a full test run. The test covers the > following

Re: [PATCH v2 0/5] crypto: add algif_akcipher user space API

Hi Stephan, >>> Albeit that all sounds like the crown jewel, how do you propose that shall >>> happen? >>> >>> Assume that you have a web server that has a pub and priv key in its >>> current configuration -- I guess that is the vast majority of configs. >>> >>> Can you please elaborate how the

[PATCH] crypto: Add support for ALG_SET_KEY_ID for skcipher

to the keys subsystem and might need to be exposed to usage by the crypto subystem first. This is just a RFC and not for merging !!! Signed-off-by: Marcel Holtmann <mar...@holtmann.org> --- crypto/af_alg.c | 14 ++ crypto/algif_skcipher.c

Re: [PATCH] crypto: Add support for ALG_SET_KEY_ID for skcipher

Hi Stephan, >> This adds support for a new socket options called ALG_SET_KEY_ID that >> allows providing the symmetric key via a key serial from the keys >> subsystem. >> >> NOTE: Currently we do not have a dedicated symmetric key type and using >> the user key type is not optional. Also

Re: [PATCH 4/4] crypto: RSA padding algorithm

Hi Stephan, >> This patch adds PKCS#1 v1.5 standard RSA padding as a separate template. >> This way an RSA cipher with padding can be obtained by instantiating >> "pkcs1pad(rsa)". The reason for adding this is that RSA is almost >> never used without this padding (or OAEP) so it will be needed

Re: [PATCH v2 3/5] crypto: AF_ALG -- add setpubkey setsockopt call

Hi Stephan, > For supporting asymmetric ciphers, user space must be able to set the > public key. The patch adds a new setsockopt call for setting the public > key. > > Signed-off-by: Stephan Mueller > --- > crypto/af_alg.c | 14 +++--- >

Re: [RFC PATCH] crypto: RSA padding transform

Hi Andrzej, >>> I can see now that with all these padding schemes there will be more buffer >>> copied on top of this, so I wonder if it still make sense. >>> Herbert? >> >> When the padding stuff comes into play, I think the SGL approach avoids >> memcpy() invocations. >> >> For example,

[PATCH] crypto: Fix ASN.1 key handling for RSA akcipher

The RSA algorithm provides two ASN.1 key types. One for RSA Private Key and another for RSA Public Key. Use these two already defined ASN.1 definitions instead of inventing a new one. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- crypto/Makefile | 9 ++--- crypto

Re: [PATCH] crypto: Fix ASN.1 key handling for RSA akcipher

Hi Stephan, The RSA algorithm provides two ASN.1 key types. One for RSA Private Key and another for RSA Public Key. Use these two already defined ASN.1 definitions instead of inventing a new one. Signed-off-by: Marcel Holtmann mar...@holtmann.org --- crypto/Makefile | 9

Re: [PATCH] crypto: Fix ASN.1 key handling for RSA akcipher

Hi Tadeusz, +++ b/crypto/rsaprivatekey.asn1 @@ -0,0 +1,13 @@ +RSAPrivateKey ::= SEQUENCE { +version Version, +modulus INTEGER ({ rsa_get_n }),-- n +publicExponent INTEGER ({ rsa_get_e }),-- e +privateExponent INTEGER ({ rsa_get_d }),

Re: [PATCH 15/26] Bluetooth: Use skcipher and hash

Hi Herbert, > This patch replaces uses of blkcipher with skcipher and the long > obsolete hash interface with shash. > > Signed-off-by: Herbert Xu <herb...@gondor.apana.org.au> Acked-by: Marcel Holtmann <mar...@holtmann.org> > --- >

Re: [PATCH] crypto: implement DH primitives under akcipher API

Hi Salvatore, > Implement Diffie-Hellman primitives required by the scheme under the > akcipher API. Here is how it works. > 1) Call set_pub_key() by passing DH parameters (p,g) in PKCS3 format > 2) Call set_priv_key() to set your own private key (xa) in raw format this combination seems odd

Re: [PATCH] crypto: implement DH primitives under akcipher API

Hi Tadeusz, >>> In this way we can define a generic user side of the key exchange interface, and on the the driver side of the akcipher, the implementations would overload the existing akcipher encrypt(), decrypt(), set_pub_key(), set_priv_key() methods and do what

Re: [PATCH V2] crypto: implement DH primitives under akcipher API

Hi Salvatore, > Implement Diffie-Hellman primitives required by the scheme under the > akcipher API. Here is how it works. > 1) Call set_pub_key() by passing DH parameters (p,g) in PKCS3 format > 2) Call set_priv_key() to set your own private key (xa) in raw format > 3) Call decrypt() without

Re: [PATCH] crypto: implement DH primitives under akcipher API

Hi Stephan, >>> +static int dh_check_params_length(unsigned int p_len) >>> +{ >>> + switch (p_len) { >>> + case 768: >>> + case 1024: >>> + case 1536: >>> + case 2048: >>> + case 3072: >>> + case 4096: >>> +

Re: [PATCH] crypto: implement DH primitives under akcipher API

Hi Tadeusz, >> And I have the feeling that akcipher is not the best approach for adding a >> key exchange method. I think we need a new method for doing exactly that. At >> the base of it, the key exchange is fundamentally different. > > It is unfortunate that, unlike the symmetric ciphers,

Re: [PATCH] crypto: implement DH primitives under akcipher API

Hi Salvatore, >>> Implement Diffie-Hellman primitives required by the scheme under the >>> akcipher API. Here is how it works. >>> 1) Call set_pub_key() by passing DH parameters (p,g) in PKCS3 format >>> 2) Call set_priv_key() to set your own private key (xa) in raw format >> >> this combination

Re: [PATCH 1/2 v2] crypto: Key-agreement Protocol Primitives API (KPP)

Hi Herbert, >> Add key-agreement protocol primitives (kpp) API which allows to >> implement primitives required by protocols such as DH and ECDH. >> The API is composed mainly by the following functions >> * set_params() - It allows the user to set the parameters known to >> both parties

Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API

rimitives API (KPP) > crypto: kpp - Add DH software implementation > crypto: kpp - Add ECDH software support we have tested this with the Bluetooth subsystem to use ECDH for key generation and shared secret generation. This seems to work as expected. Feel free to merge this patchset. Acked

Re: [PATCH] Bluetooth: convert smp module to crypto kpp API

Hi Salvatore, > This patch has *not* been tested as I don't have the hardware. > It's purpose is to show how to use the kpp API. > > Based on https://patchwork.kernel.org/patch/9022371/ actually you should be able to verify this without hardware. The BlueZ userspace package contains

Re: KPP questions and confusion

Hi Tudor, >>> I am confused about several things in the new key agreement code. >>> >>> net/bluetooth/smp.c in two places generates random bytes for the >>> private_key argument to >>> net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the >>> private key is static within the

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >>> 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

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >> 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

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >> I also would like to have more of those algorithms exposed to userspace, >> and I'd like to make sure the API is a good fit. There was extensive >> discussion of AF_ALG akcipher last year. v8 of the patch set updates the >> implementation but doesn't address the API concerns that

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Stephan, >>> The first part is clearly where AF_ALG fits and keyctl does not. This is >>> provided with the current patch set. As the keyctl API only handles, well, >>> keys, access to the raw ciphers may not be possible through this API. And >>> let us face it, a lot of user space code shall

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Mat, >> This patch set adds the AF_ALG user space API to externalize the >> asymmetric cipher API recently added to the kernel crypto API. > > ... > >> Changes v8: >> * port to kernel 4.13 >> * port to consolidated AF_ALG code >> >> Stephan Mueller (4): >> crypto: AF_ALG -- add sign/verify

Re: KPP questions and confusion

Hi Kyle, > I am confused about several things in the new key agreement code. > > net/bluetooth/smp.c in two places generates random bytes for the > private_key argument to > net/bluetooth/ecdh_helper.c:generate_ecdh_keys, which suggests the > private key is static within the function. However,

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

Hi Tudor, > This patch set introduces Microchip / Atmel ECC driver. > > The first patch adds some helpers that will be used by fallbacks to > kpp software implementations. > > The second patch adds ECDH support for the ATECC508A (I2C) > cryptographic engine. The I2C interface is designed to

Re: [PATCH 0/3] crypto: introduce Microchip / Atmel ECC driver

Hi Tudor, >>> This patch set introduces Microchip / Atmel ECC driver. >>> >>> The first patch adds some helpers that will be used by fallbacks to >>> kpp software implementations. >>> >>> The second patch adds ECDH support for the ATECC508A (I2C) >>> cryptographic engine. The I2C interface is

Re: ecdh: generation and retention of ecc privkey in kernel/hardware

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. > >

Re: [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

Hi Ted, >> This protocol uses lots of complex cryptography that relies on securely >> generated random numbers. Thus, it's important that the RNG is actually >> seeded before use. Fortuantely, it appears we're always operating in >> process context (there are many GFP_KERNEL allocations and other

Re: [PATCH v4 12/13] bluetooth/smp: ensure RNG is properly seeded before ECDH use

Hi Jason, >> yes, there are plenty of commands needed before a controller becomes usable. > > That doesn't clearly address with precision what Ted was wondering. > Specifically, the inquiry is: can you confirm with certainty whether > or not all calls to get_random_bytes() in the bluetooth

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

Hi Tudor, > akcipher can work with its own internal keys, now that we have crypto > accelerators that can generate keys that never leave the hardware. Going > through the kernel's key subsystem seems superfluous in this case. > > I also understand the need of going through the kernel's key

Re: [RFC PATCH 0/2] let the crypto subsystem generate the ecc privkey

Hi Tudor, > That Bluetooth SMP knows about the private key is pointless, since the > detection of debug key usage is actually via the public key portion. > With this patch set, the Bluetooth SMP will stop keeping a copy of the > ecdh private key, except when using debug keys. This way we let the

Re: [RESEND RFC PATCH 1/2] Bluetooth: move ecdh allocation outside of ecdh_helper

Hi Tudor, > This change is a prerequisite for letting the crypto subsystem generate > the ecc private key for ecdh. Before this change, a new crypto tfm was > allocated, each time, for both key generation and shared secret > computation. With this change, we allocate a single tfm for both cases.

Re: [RESEND RFC PATCH 2/2] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi Tudor, > That Bluetooth SMP knows about the private key is pointless, since the > detection of debug key usage is actually via the public key portion. > With this patch, the Bluetooth SMP will stop keeping a copy of the > ecdh private key, except when using debug keys. This way we let the >

Re: [v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi Tudor, > That Bluetooth SMP knows about the private key is pointless, since the > detection of debug key usage is actually via the public key portion. > With this patch, the Bluetooth SMP will stop keeping a copy of the > ecdh private key and will let the crypto subsystem to generate and >

Re: [v2 PATCH 5/5] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi Tudor, >>> That Bluetooth SMP knows about the private key is pointless, since the >>> detection of debug key usage is actually via the public key portion. >>> With this patch, the Bluetooth SMP will stop keeping a copy of the >>> ecdh private key and will let the crypto subsystem to generate

Re: [v2 PATCH 0/5] Bluetooth: let the crypto subsystem generate the ecc privkey

Hi Tudor, > That Bluetooth SMP knows about the private key is pointless, since the > detection of debug key usage is actually via the public key portion. > With this patch set, the Bluetooth SMP will stop keeping a copy of the > ecdh private key. We let the crypto subsystem to generate and handle

Re: [PATCH v8 0/4] crypto: add algif_akcipher user space API

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