[PATCH v3 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller --- crypto/rng.c

[RFC PATCH] KEYS: add SP800-56A KDF support for DH

ills the caller buffer up to its size. The patch is tested with a new test added to the keyutils user space code which uses a CAVS test vector testing the compliance with SP800-56A. Signed-off-by: Stephan Mueller --- include/uapi/linux/keyctl.h | 10 + security/keys/Kconfig | 1 + secu

[PATCH v3 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 226 +++ crypto/testmgr.h | 110 +++ 2 files changed, 336 insertions(+) diff --git a/crypto

[PATCH v3 0/4] crypto: Key Derivation Function (SP800-108)

the first patch by adding a template handling for random number generators based on the same logic as for keyed hashes. Changes v3: * port testmgr patch to current cryptodev-2.6 tree * add non-keyed KDF references to testmgr.c Changes v2: * port to 4.7-rc1 Stephan Mueller (4): crypto: add

[PATCH v3 3/4] crypto: kdf - SP800-108 Key Derivation Function

-by: Stephan Mueller --- crypto/kdf.c | 514 +++ 1 file changed, 514 insertions(+) create mode 100644 crypto/kdf.c diff --git a/crypto/kdf.c b/crypto/kdf.c new file mode 100644 index 000..b39bddf --- /dev/null +++ b/crypto/kdf.c @@ -0,0

Re: [PATCH] DH support: add KDF handling support

ring> > > > > The test to verify the code is based on a test vector used for the CAVS > > testing of SP800-56A. > > > > Signed-off-by: Stephan Mueller > > --- > > keyctl.c | 14 +- > > keyutils

Re: [PATCH] DH support: add KDF handling support

Am Donnerstag, 14. Juli 2016, 04:00:57 schrieb Jeffrey Walton: Hi Jeffrey, > > Note, as shared secrets potentially post-processed by a KDF usually are > > again used as key or data encryption keys, they need to be > > truncated/expanded to a specific length anyway. A KDF inherently provides > > t

Re: [RFC PATCH] KEYS: add SP800-56A KDF support for DH

Am Donnerstag, 14. Juli 2016, 17:45:59 schrieb Mat Martineau: Hi Mat, > > Signed-off-by: Stephan Mueller > > --- > > include/uapi/linux/keyctl.h | 10 + > > security/keys/Kconfig | 1 + > > security/keys/dh.c | 98 > > +++

Re: [PATCH v3 1/4] crypto: add template handling for RNGs

Am Montag, 18. Juli 2016, 15:14:17 schrieb Herbert Xu: Hi Herbert, > > > > diff --git a/crypto/rng.c b/crypto/rng.c > > index b81cffb..92cc02a 100644 > > --- a/crypto/rng.c > > +++ b/crypto/rng.c > > @@ -232,5 +232,36 @@ void crypto_unregister_rngs(struct rng_alg *algs, int > > count) } > > EXPOR

Re: [PATCH v3 1/4] crypto: add template handling for RNGs

Am Montag, 18. Juli 2016, 11:23:26 schrieb Sandy Harris: Hi Sandy, > On Mon, Jul 18, 2016 at 3:14 AM, Herbert Xu wrote: > > Stephan Mueller wrote: > >> This patch adds the ability to register templates for RNGs. RNGs are > >> "meta" mechanisms using raw

Re: a few questions on AF_ALG specification (AEAD, socket/connection, ...)

Am Dienstag, 26. Juli 2016, 13:48:21 CEST schrieb Nicolas Brunie: Hi Nicolas, > Hi All, > I am developping a driver for a crypto offloading solution which > uses the AF_ALG interface. I am trying to stay as close as possible to > the specification but apart from the kernel crypto source code

Re: [PATCH] DH support: add KDF handling support

Am Mittwoch, 27. Juli 2016, 08:55:31 CEST schrieb David Howells: Hi David, > Mat Martineau wrote: > > > Though, shall I stuff the wrapper code back into the existing dh_compute > > > functions or can I leave them as separate functions? > > > > I'm not sure. In the existing code there's one keyc

Re: getrandom waits for a long time when /dev/random is insufficiently read from

Am Donnerstag, 28. Juli 2016, 18:07:32 CEST schrieb Alex Xu: Hi Alex, > Linux 4.6, also tried 4.7, qemu 2.6, using this C program: I am not sure what problem you are referring to, but that is an expected behavior. You get partial reads when reading from /dev/random with a minimum of 64 bits.

Re: getrandom waits for a long time when /dev/random is insufficiently read from

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > wrote: > > > And finally, you have a coding error that

Re: getrandom waits for a long time when /dev/random is insufficiently read from

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something te

Re: a few questions on AF_ALG specification (AEAD, socket/connection, ...)

The key is set on a socket. The IV is given with the connection. > > NB > > > > - Mail original - > De: "Tadeusz Struk" > À: "Stephan Mueller" , "Nicolas Brunie" > Cc: "Linux Crypto Mailing List" > > Envoyé

[PATCH v4 4/4] crypto: kdf - enable compilation

Include KDF into Kconfig and Makefile for compilation. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 7 +++ crypto/Makefile | 1 + 2 files changed, 8 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index a9377be..91ef2a6 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig

[PATCH v2] KEYS: add SP800-56A KDF support for DH

Signed-off-by: Stephan Mueller --- Documentation/security/keys.txt | 35 +--- include/linux/compat.h | 7 +++ include/uapi/linux/keyctl.h | 7 +++ security/keys/Kconfig | 1 + security/keys/compat.c | 34 +++- security/keys/dh.c

[PATCH v4 0/4] crypto: Key Derivation Function (SP800-108)

in the RNG instance handling as requested by Herbert * move the instance handling code from include/crypto/rng.h to include/crypto/internal/rng.h Changes v3: * port testmgr patch to current cryptodev-2.6 tree * add non-keyed KDF references to testmgr.c Changes v2: * port to 4.7-rc1 Stephan

[PATCH v4 3/4] crypto: kdf - SP800-108 Key Derivation Function

-by: Stephan Mueller --- crypto/kdf.c | 508 +++ 1 file changed, 508 insertions(+) create mode 100644 crypto/kdf.c diff --git a/crypto/kdf.c b/crypto/kdf.c new file mode 100644 index 000..6f9f082 --- /dev/null +++ b/crypto/kdf.c @@ -0,0

[PATCH v2] DH support: add KDF handling support

SP800-56A. Signed-off-by: Stephan Mueller --- Makefile | 1 + keyctl.c | 125 +++ keyutils.c | 44 keyutils.h | 15 +++ man/keyct

[PATCH v4 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 226 +++ crypto/testmgr.h | 110 +++ 2 files changed, 336 insertions(+) diff --git a/crypto

[PATCH v4 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller --- cr

Re: [PATCH v2] DH support: add KDF handling support

Am Donnerstag, 4. August 2016, 20:38:59 CEST schrieb Stephan Mueller: Hi Mat, > @@ -1663,6 +1668,7 @@ static void act_keyctl_dh_compute(int argc, char > *argv[]) } > > printf("%02hhx", *p); > + *p = 0x00; /* zeroize bu

Re: [PATCH v2] DH support: add KDF handling support

Am Donnerstag, 4. August 2016, 13:57:27 CEST schrieb Mat Martineau: Hi Mat, > Stephan, > > On Thu, 4 Aug 2016, Stephan Mueller wrote: > > Hi Mat, David, > > > > this patch covers all comments you raised. I also added a man page > > for the new API calls. &

Re: [PATCH v2] KEYS: add SP800-56A KDF support for DH

Am Donnerstag, 4. August 2016, 13:41:58 CEST schrieb Mat Martineau: Hi Mat, I will take care of your comments in the next iteration. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info a

Re: [PATCH v2] KEYS: add SP800-56A KDF support for DH

Am Donnerstag, 4. August 2016, 13:41:58 CEST schrieb Mat Martineau: Hi Mat, > > + > > +long keyctl_dh_compute(struct keyctl_dh_params __user *params, > > + char __user *buffer, size_t buflen, > > + struct keyctl_kdf_params __user *kdf) > > +{ > > + struct keyct

[RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

the input_pool but it is assumed to have no entropy. When the ATH9K RNG changes to use the HW RNG framework, it may re-enable the entropy estimation considering that a user can change that value at boot and runtime. Signed-off-by: Stephan Mueller --- drivers/net/wireless/ath/ath9k/rng.c | 3 +--

Re: [RFC][PATCH] RANDOM: ATH9K RNG delivers zero bits of entropy

Am Samstag, 6. August 2016, 19:45:51 CEST schrieb Jason Cooper: Hi Jason, > Hi Stephan, > > On Fri, Aug 05, 2016 at 05:08:14PM +0200, Stephan Mueller wrote: > > Hi Ted, Herbert, > > > > I sent a question to the ATH9K RNG some time ago to the developers. > > See

[PATCH v3] DH support: add KDF handling support

ith "other information string: dh_compute_kdf_oi where the OI string is provided on STDIN. The test to verify the code is based on a test vector used for the CAVS testing of SP800-56A. Signed-off-by: Stephan Mueller --- Makefile |

Re: [PATCH v2] KEYS: add SP800-56A KDF support for DH

Am Freitag, 5. August 2016, 09:08:59 CEST schrieb Mat Martineau: Hi Mat, > > > > When trying to implement it, I think that it would even be more confusing, > > because we need a conditional in any case. Do you like > > > > return __keyctl_dh_compute(params, buffer, buflen, (kdf) ? &kdfcopy : >

[PATCH v3] KEYS: add SP800-56A KDF support for DH

ested size, this patch fills the caller buffer up to its size. The patch is tested with a new test added to the keyutils user space code which uses a CAVS test vector testing the compliance with SP800-56A. Signed-off-by: Stephan Mueller --- Documentation/security/keys.txt | 35 ++--- inc

[PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

. The RNG still feeds data into the input_pool but it is assumed to have no entropy. When the ATH9K RNG changes to use the HW RNG framework, it may re-enable the entropy estimation considering that a user can change that value at boot and runtime. Reviewed-by: Jason Cooper Signed-off-by: Stephan

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

pin, please help and offer another solution. > > -- > Miaoqing > > -Original Message- > From: Stephan Mueller [mailto:smuel...@chronox.de] > Sent: Sunday, August 07, 2016 5:36 PM > To: Ted Tso > Cc: herb...@gondor.apana.org.au; linux-ker...@vger.kernel.org

Re: AF_ALG broken?

Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux: Hi Russell, > Hi, > > When trying to use the openssl AF_ALG module with 4.8-rc1 with imx > caam, I get this: > > $ OPENSSL_CONF=/shared/crypto/openssl-imx.cnf strace openssl dgst -md5 > socket(PF_ALG, SOCK_SEQPACKET, 0)

Re: AF_ALG broken?

Am Montag, 8. August 2016, 20:18:32 CEST schrieb Stephan Mueller: Hi Stephan, > Am Montag, 8. August 2016, 17:44:27 CEST schrieb Russell King - ARM Linux: > > Hi Russell, > > > Hi, > > > > When trying to use the openssl AF_ALG module with 4.8-rc1

Re: [PATCH 2/2] ath9k: disable RNG by default

, especially on embedded systems. > > Signed-off-by: Miaoqing Pan As a short term solution: Acked-by: Stephan Mueller But as Jason outlined, there should be nothing that prevents using this code with the HW Random framework. This framework also has logic to limit the rate of injection a

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing: Hi Miaoqing, Herbert, Matt, > Hi Stephan, > > So your suggestion is to use HW Random framework ? Actually, which was > done by the commit 6301566e0b2d ("ath9k: export HW random number > generator"), but it was reverted, you can

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote: > > Herbert, Matt, should such noise sources be added to the HW random > > framework? The thing is that the in-kernel HW random to input_po

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote: > > But shouldn't the default of the rngd then be adjusted a bit? > > Please elaborate. in rngd_linux.c:random_add_entropy(vo

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu: Hi Herbert, > > You're supposed to tweak the quality of the input. In any case, How is that tweak supposed to happen? The rngd does not allow changing the amount of read data relative to the assumed entropy. > this is not affected

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote: > > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu: > > > > Hi Herbert, > > > > > You're suppos

[PATCH v5 4/4] crypto: kdf - enable compilation

Include KDF into Kconfig and Makefile for compilation. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 7 +++ crypto/Makefile | 1 + 2 files changed, 8 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 84d7148..16f3221 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig

[PATCH v5 0/4] crypto: Key Derivation Function (SP800-108)

references to testmgr.c Changes v2: * port to 4.7-rc1 Stephan Mueller (4): crypto: add template handling for RNGs crypto: kdf - add known answer tests crypto: kdf - SP800-108 Key Derivation Function crypto: kdf - enable compilation crypto/Kconfig| 7 + crypto/Makefile

[PATCH v5 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller --- cr

[PATCH v5 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 226 +++ crypto/testmgr.h | 110 +++ 2 files changed, 336 insertions(+) diff --git a/crypto

[PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

-by: Stephan Mueller --- crypto/kdf.c | 508 +++ 1 file changed, 508 insertions(+) create mode 100644 crypto/kdf.c diff --git a/crypto/kdf.c b/crypto/kdf.c new file mode 100644 index 000..6f9f082 --- /dev/null +++ b/crypto/kdf.c @@ -0,0

Re: testmgr.h

Am Dienstag, 9. August 2016, 08:21:43 CEST schrieb Gary R Hook: Hi Gary, > Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h? > Two cases: > > 1) Tests from the NIST document(s) on various ciphers and hashes wherein > we add to an existing set of tests? For example, 3DES

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi: Hi Tapas, > Hello, > > I am using vanilla kernel-4.7 source. It crashes with the following when > booted with ³fips=1 boot=/dev/sda1² option at the kernel command line > argument. The kernel only allows 2k and 3k RSA keys in FIPS

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi: Hi Tapas, David, > Hi Stephan, > > If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256") > tells about the key size used. > I am using “sha256”. Initially, I was using “sha512” which I thought could > be causing p

Re: RSA key size not allowed in FIPS

rote: > > > >Embarrassing! Yes, I just saw this while you are pressing send on that > >replyŠ default bits were set to 4096 in x509.genkey. :-( > > > >I am trying out with 2048 bits. I will confirm. > > > >-Tapas > > > > > >On 8/9/16, 9:

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > Following up from the other thread: > > While trying to boot in FIPS mode, kernel panics with the following > message. So far, I don¹t have success to get more information about which > module or symbo

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi: Hi Tapas, Herbert, > Hi Stephan, > > Thanks. I have already tried that. ‘drbg’ module is loaded fine in a > non-fips mode. Here are output from some commands. There is something strange going on. I have to compile the DRBG static

[PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller: Hi Tapas, I think I found the issue. Can you please test the attached patch? ---8<--- When calling the DRBG health test in FIPS mode, the Jitter RNG is not yet present in the kernel crypto API which will cause

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > FIPS RNG test is supposed to be run on the output of an RNG, and not on the > RNG entropy source. It is not surprising that the RNG input fails the > entropy tests from NIST. Check the following exa

[PATCH v4] KEYS: add SP800-56A KDF support for DH

ested size, this patch fills the caller buffer up to its size. The patch is tested with a new test added to the keyutils user space code which uses a CAVS test vector testing the compliance with SP800-56A. Signed-off-by: Stephan Mueller --- Documentation/security/keys.txt | 35 ++--- inc

[PATCH v4] DH support: add KDF handling support

ith "other information string: dh_compute_kdf_oi where the OI string is provided on STDIN. The test to verify the code is based on a test vector used for the CAVS testing of SP800-56A. Signed-off-by: Stephan Mueller --- Makefile |

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > Would you please provide a recent NIST document which asks the entropy > source to pass the NIST randomness tests ? See FIPS 140-2 IG 7.15 which explicitly references SP800-22. Ciao Stephan -- To

[PATCH] crypto: XTS - remove test that will fail in FIPS mode

sts available for XTS, this patch simply removes the offending test vectors. Reported-by: Tapas Sarangi Signed-off-by: Stephan Mueller --- crypto/testmgr.h | 36 1 file changed, 36 deletions(-) diff --git a/crypto/testmgr.h b/crypto/testmgr.h index acb6

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > For those less perfect noise source, can't pass the FIPS test. > > static int update_kernel_random(int random_step, > unsigned char *buf, fips_ctx_t *fipsctx_in) > { > unsigned char

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing: Hi Miaoqing, > Hi Stephan, > > NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the > amount of min entropy the source provides, and not to decide if the source > has passed the tests or failed. See > > htt

Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH

Am Dienstag, 9. August 2016, 15:48:00 CEST schrieb Mat Martineau: Hi Mat, > On Sat, 6 Aug 2016, Stephan Mueller wrote: > > diff --git a/security/keys/internal.h b/security/keys/internal.h > > index a705a7d..7659b52 100644 > > --- a/security/keys/internal.h > > +++

[PATCH v6 5/5] crypto: LRNG - add ChaCha20 support

numbers. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 1 - crypto/Makefile | 7 +- crypto/lrng_standalone.c | 220 +++ 3 files changed, 226 insertions(+), 2 deletions(-) create mode 100644 crypto/lrng_standalone.c diff --git a

[PATCH v6 2/5] random: conditionally compile code depending on LRNG

-off-by: Stephan Mueller --- drivers/char/random.c | 8 include/linux/genhd.h | 5 + include/linux/random.h | 7 ++- 3 files changed, 19 insertions(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index 3efb3bf..730a12e 100644 --- a/drivers/char

[PATCH v6 1/5] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/crypto

[PATCH v6 3/5] crypto: Linux Random Number Generator

ition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the legacy /dev/random implementation. Signed-off-by: Stephan Mueller --- crypto/lrng_base.c | 1960 +++ crypto/lrng_kcapi.c | 16

[PATCH v6 4/5] crypto: LRNG - enable compile

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 11 +++ crypto/Makefile | 2 ++ 2 files changed, 13 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 84d7148..71df7fc 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1665,6 +1665,17

[PATCH v6 0/5] /dev/random - a new approach

seeding cryptographic daemons. Note, this test result was obtained for different architectures, such as x86 64 bit, x86 32 bit, ARM 32 bit and MIPS 32 bit. [1] http://www.chronox.de/lrng/doc/lrng.pdf [2] http://www.chronox.de/lrng.html Stephan Mueller (5): crypto: DRBG - externalize DRBG

Re: [PATCH v6 4/5] crypto: LRNG - enable compile

Am Donnerstag, 11. August 2016, 21:50:15 CEST schrieb kbuild test robot: Hi, > Hi Stephan, > > [auto build test ERROR on cryptodev/master] > [also build test ERROR on v4.8-rc1] > [cannot apply to next-20160811] > [if your patch is applied to the wrong git tree, please drop us a note to > help im

Re: [PATCH] crypto: XTS - remove test that will fail in FIPS mode

Am Donnerstag, 11. August 2016, 19:42:54 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > Any other ideas about this problem ? Since XTS is not amongst the > self-tests as you observed, is it safe to disable .fips_allowed for > xts(aes) in testmgr.c ? If you do that, none of your XTS imp

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Donnerstag, 11. August 2016, 17:36:32 CEST schrieb Theodore Ts'o: Hi Theodore, > On Thu, Aug 11, 2016 at 02:24:21PM +0200, Stephan Mueller wrote: > > The following patch set provides a different approach to /dev/random which > > I call Linux Random Number Generator (LRNG

Re: FIPS self test failures (kernel panic) in kernel-4.7

Am Donnerstag, 11. August 2016, 21:55:05 CEST schrieb Tapas Sarangi: Hi Tapas, > Hello, > > A few algorithms are failing Œalg self tests' during kernel boot into FIPS > mode (fips=1), causing a kernel panic (see below). I am using vanilla > kernel-4.7 source for these tests. > > These messages

Re: JZ4780 RNG and entropy depletion

Am Sonntag, 14. August 2016, 01:33:32 CEST schrieb Jeffrey Walton: Hi Jeffrey, > Hi Everyone, > > I have a MIPSEL ci20 dev board for testing. The board has a hardware > based rng, but its suffering entropy depletion. I have Debian's > rng-tools package installed. > > The board lacks /dev/hwrng.

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Freitag, 12. August 2016, 15:22:08 CEST schrieb Theodore Ts'o: Hi Theodore, > On Fri, Aug 12, 2016 at 11:34:55AM +0200, Stephan Mueller wrote: > > - correlation: the interrupt noise source is closely correlated to the > > HID/ > > block noise sources. I see that the

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Montag, 15. August 2016, 13:42:54 CEST schrieb H. Peter Anvin: Hi H, > On 08/11/16 05:24, Stephan Mueller wrote: > > * prevent fast noise sources from dominating slow noise sources > > > > in case of /dev/random > > Can someone please explain if and why this is

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

Am Dienstag, 16. August 2016, 16:57:45 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 02:28:37PM +0200, Stephan Mueller wrote: > > The SP800-108 compliant Key Derivation Function is implemented as a > > random number generator considering that it behaves like

Re: [PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

Am Dienstag, 16. August 2016, 17:13:47 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 16, 2016 at 11:11:47AM +0200, Stephan Mueller wrote: > > Conceptually, a KDF is a random number generator by generating arbitrarily > > sized strings from a fixed "seed". Th

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 16:55:52 CEST schrieb Stephan Mueller: Hi Tapas, David, > > David, the x509.genkey file seems to generate a 4k RSA key per default. This > will cause a panic with fips=1 as only 2k and 3k keys are allowed. Just yesterday, a new ruling came out from NIST all

[PATCH v2] crypto: XTS - remove test that will fail in FIPS mode

XTS keys where the AES key is identical to the tweak key is forbidden. Thus, the self test with such property will fail in FIPS mode. As we have other tests available for XTS, this patch simply removes the offending test vectors. Reported-by: Tapas Sarangi Signed-off-by: Stephan Mueller --- cry

Re: [PATCH v6 0/5] /dev/random - a new approach

Am Dienstag, 16. August 2016, 15:28:45 CEST schrieb H. Peter Anvin: Hi Peter, > > > > There are two motivations for that: > > > > - the current /dev/random is compliant to NTG.1 from AIS 20/31 which > > requires (in brief words) that entropy comes from auditible noise > > sources. Currently in

Re: [PATCH v2] crypto: XTS - remove test that will fail in FIPS mode

Am Mittwoch, 17. August 2016, 14:52:32 CEST schrieb Tapas Sarangi: Hi Tapas, (please, do not top-post) > Hi Stephan, > > Yes, can you give me some more detail about your findings on dracut-fips > !? This seems to be the major difference between our test environments > where a bunch of algorithm

Re: [PATCH v2] crypto: XTS - remove test that will fail in FIPS mode

Am Mittwoch, 17. August 2016, 15:09:11 CEST schrieb Tapas Sarangi: Hi Tapas, > Is that all the authenc() ciphers, or only some of them ? In my patch I have not yet had the chance to fully dissect the authenc issue yet. > where I had disabled .fips_allowed are mostly authenc() ciphers with > cbc

[PATCH v5] KEYS: add SP800-56A KDF support for DH

DF implements the proper truncation of the DH shared secret to the requested size, this patch fills the caller buffer up to its size. The patch is tested with a new test added to the keyutils user space code which uses a CAVS test vector testing the compliance with SP800-56A. Signed-off-by: St

[PATCH v5] DH support: add KDF handling support

provided on STDIN. The test to verify the code is based on a test vector used for the CAVS testing of SP800-56A. Signed-off-by: Stephan Mueller --- Makefile | 1 + keyctl.c | 133 ++

Re: [PATCH -next] crypto: drbg - fix error return code

Am Samstag, 20. August 2016, 15:06:51 CEST schrieb Wei Yongjun: Hi Wei, > Fix to return a negative error code from the error handling > case instead of 0. > > Signed-off-by: Wei Yongjun Acked-by: Stephan Mueller Ciao Stephan -- To unsubscribe from this list: send the line "

[PATCH] crypto: FIPS - allow RSA keys >= 2048 bits

ity to boot the kernel in FIPS mode, because certs/x509.genkey defines a 4096 bit RSA key per default. This key causes the RSA signature verification to fail in FIPS mode without the patch below. Signed-off-by: Stephan Mueller --- crypto/rsa_helper.c | 4 ++-- 1 file changed, 2 insertions

Re: Problems with cbc(aes) and do_alg0test()

Am Dienstag, 23. August 2016, 22:44:39 CEST schrieb Michael McKay: Hi Michael, > We are writing a device driver with kernel v3.14, and trying to encrypt some > data using the Linux kernel algorithm “cbc(aes)”. Our /proc/crypto shows > the following is loaded: driver “cbc-aes-aesni”, module “aesni

[PATCH] crypto: FIPS - allow tests to be disabled in FIPS mode

key is disabled in FIPS mode. This test vector violates the FIPS requirement that both keys must be different. Reported-by: Tapas Sarangi Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 9 + crypto/testmgr.h | 4 2 files changed, 13 insertions(+) diff --git a/crypto/testmgr.c

sha1_mb broken

Hi, I tried to execute tests with sha1_mb. The execution simply stalls when invoking a digest operation -- i.e. the digest operation does not finish. After some time after invoking the hashing operation, the following log appears (note, the kccavs_* functions are my test code; that test code w

Re: CONFIG_FIPS without module loading support?

Am Mittwoch, 31. August 2016, 20:32:42 CEST schrieb NTU: Hi NTU, > Hello, > > CRYPTO_FIPS depends on MODULE_SIG and I understand why it would as you > wouldn't want unsigned modules from external sources being loaded. If > CONFIG_MODULES is disabled though (no module loading) there are no > modu

Re: Who will copy the AAD data to dest. buffer

Am Samstag, 3. September 2016, 10:45:08 CEST schrieb Harsh Jain: Hi Harsh, > Thanks Herbert for clarification. It means Libkcapi documentation > needs update of chapter "Aead Cipher API". Fixed, I will release a new version shortly. Thanks for the pointer. Ciao Stephan -- To unsubscribe from

algif_akcipher

Hi Herbert, David, may I inquire for the plans with algif_akcipher? The reason I am asking is whether this interface may be accepted or whether a key rings based solution is used and whether I can leave or remove the akcipher related API from my libkcapi. Thanks a lot Stephan -- To unsubscribe

BUG while working on algif_skcipher AIO support

Hi Herbert, here is a reliably producable bug that I triggered while educating my libkcapi about AIO support. [70129.671557] page:ea0001361d80 count:0 mapcount:0 mapping: (null) index:0x0 [70129.671560] flags: 0x1c() [70129.671562] page dumped because: VM_BUG_ON_PAGE(

BUG in recvmsg using io_submit

Hi Herbert, another one, different than the first report [71972.773115] page:ea0001fabf40 count:0 mapcount:0 mapping: (null) index:0x0 [71972.773118] flags: 0x1c() [71972.773119] page dumped because: VM_BUG_ON_PAGE(page_ref_count(page) == 0) [71972.773140]

Re: BUG in recvmsg using io_submit

Am Donnerstag, 8. September 2016, 04:52:08 CEST schrieb Stephan Mueller: Hi, > Hi Herbert, > > another one, different than the first report Please note that the error seems to be triggered due to a bad use of the user space interface: When submitting the iov, I told the kernel that

[PATCH] crypto: only call put_page used pages

SGL is freed, the code must only call put_page for an SG if there was a page assigned to it in the first place. This fixes a kernel crash when using io_submit with more than one iocb. Signed-off-by: Stephan Mueller --- crypto/algif_skcipher.c | 9 +++-- 1 file changed, 7 insertions(+)

[PATCH v2] crypto: only call put_page used pages

ing io_submit with more than one iocb. Signed-off-by: Stephan Mueller --- crypto/algif_skcipher.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index 28556fc..d7acb73 100644 --- a/crypto/algif_skcipher.c +++ b/cry

[PATCH] crypto: call put_page on used pages only

this patch should go to 4.8 and to stable as well. ---8<--- Ensure that put_page is only invoked on pages that were used by algif_skcipher. Signed-off-by: Stephan Mueller --- crypto/algif_skcipher.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/algif_skcipher.

algif_aead: AIO broken with more than one iocb

Hi Herbert, The AIO support for algif_aead is broken when submitting more than one iocb. The break happens in aead_recvmsg_async at the following code: /* ensure output buffer is sufficiently large */ if (usedpages < outlen) goto free; The reason is that when sub

Re: algif_aead: AIO broken with more than one iocb

Am Sonntag, 11. September 2016, 08:43:00 CEST schrieb Jeffrey Walton: Hi Jeffrey, > > The AIO support for algif_aead is broken when submitting more than one > > iocb. > > The break happens in aead_recvmsg_async at the following code: > I think the kernel needs to take a half step back, and add th

<    5   6   7   8   9   10   11   12   13   14   >