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

Am Freitag, 17. Juni 2016, 11:26:23 schrieb Sandy Harris: Hi Sandy, > David Jaša wrote: > > BTW when looking at an old BSI's issue with Linux urandom that Jarod > > Wilson tried to solve with this series: > > https://www.spinics.net/lists/linux-crypto/msg06113.html > > I was

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

Am Freitag, 17. Juni 2016, 11:26:23 schrieb Sandy Harris: Hi Sandy, > David Jaša wrote: > > BTW when looking at an old BSI's issue with Linux urandom that Jarod > > Wilson tried to solve with this series: > > https://www.spinics.net/lists/linux-crypto/msg06113.html > > I was thinking: > > 1)

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

Am Freitag, 17. Juni 2016, 15:56:13 schrieb David Jaša: Hi David, > Hi Stephan, > > thank you for your thorough reply, > > On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote: > > Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša: > > > > H

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

Am Freitag, 17. Juni 2016, 15:56:13 schrieb David Jaša: Hi David, > Hi Stephan, > > thank you for your thorough reply, > > On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote: > > Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša: > > > > H

Re: [PATCH] crypto: use timespec64 for jent_get_nstime

Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: Hi Arnd, > The jent_get_nstime() function uses __getnstimeofday() to get > something similar to a 64-bit nanosecond counter. As we want > to get rid of struct timespec to fix the y2038 overflow, > this patch changes the code to use

Re: [PATCH] crypto: use timespec64 for jent_get_nstime

Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: Hi Arnd, > The jent_get_nstime() function uses __getnstimeofday() to get > something similar to a 64-bit nanosecond counter. As we want > to get rid of struct timespec to fix the y2038 overflow, > this patch changes the code to use

Re: [patch] crypto: drbg - fix an error code in drbg_init_sym_kernel()

Am Freitag, 17. Juni 2016, 11:19:58 schrieb Stephan Mueller: Hi Stephan, > Am Freitag, 17. Juni 2016, 12:16:19 schrieb Dan Carpenter: > > Hi Dan, > > > We accidentally return PTR_ERR(NULL) which is success but we should > > return -ENOMEM. > > > > Fixes: 3

Re: [patch] crypto: drbg - fix an error code in drbg_init_sym_kernel()

Am Freitag, 17. Juni 2016, 11:19:58 schrieb Stephan Mueller: Hi Stephan, > Am Freitag, 17. Juni 2016, 12:16:19 schrieb Dan Carpenter: > > Hi Dan, > > > We accidentally return PTR_ERR(NULL) which is success but we should > > return -ENOMEM. > > > > Fixes: 3

Re: [patch] crypto: drbg - fix an error code in drbg_init_sym_kernel()

oracle.com> Acked-by: Stephan Mueller <smuel...@chronox.de> That points to an error in the documentation of skcipher_request_alloc. I will send a follow-up patch. > > diff --git a/crypto/drbg.c b/crypto/drbg.c > index ded8638..6872d15 100644 > --- a/crypto/drbg.c > +++ b/cr

Re: [patch] crypto: drbg - fix an error code in drbg_init_sym_kernel()

Am Freitag, 17. Juni 2016, 12:16:19 schrieb Dan Carpenter: Hi Dan, > We accidentally return PTR_ERR(NULL) which is success but we should > return -ENOMEM. > > Fixes: 355912852115 ('crypto: drbg - use CTR AES instead of ECB AES') > Signed-off-by: Dan Carpenter Acked-by:

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Donnerstag, 16. Juni 2016, 21:39:17 schrieb Raveendra Padasalagi: Hi Raveendra, > I need some clarification to address your comment > > "Shouldn't there be a priority here?" > > What I know regarding priority value for an algorithm > is higher the priority value it will be get selected for

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Donnerstag, 16. Juni 2016, 21:39:17 schrieb Raveendra Padasalagi: Hi Raveendra, > I need some clarification to address your comment > > "Shouldn't there be a priority here?" > > What I know regarding priority value for an algorithm > is higher the priority value it will be get selected for

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Donnerstag, 16. Juni 2016, 14:44:57 schrieb Raveendra Padasalagi: Hi Raveendra, > > Typo DFIPS? > > It's not typo, DFIPS mean here Draft FIPS 202. > Do you want me to put it in another way ? I have never seen DFIPS. Besides, most FIPS standards are drafts (including of FIPS 140-2 :-) ),

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Donnerstag, 16. Juni 2016, 14:44:57 schrieb Raveendra Padasalagi: Hi Raveendra, > > Typo DFIPS? > > It's not typo, DFIPS mean here Draft FIPS 202. > Do you want me to put it in another way ? I have never seen DFIPS. Besides, most FIPS standards are drafts (including of FIPS 140-2 :-) ),

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 16. Juni 2016, 16:59:01 schrieb Andrew Zaborowski: Hi Andrew, > Hi Stephan, > > On 16 June 2016 at 10:05, Stephan Mueller <smuel...@chronox.de> wrote: > > Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: > > > > Hi Andrew, &

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 16. Juni 2016, 16:59:01 schrieb Andrew Zaborowski: Hi Andrew, > Hi Stephan, > > On 16 June 2016 at 10:05, Stephan Mueller wrote: > > Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: > > > > Hi Andrew, > > > >> >

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: Hi Andrew, > > > > I think we have agreed on dropping the length enforcement at the interface > > level. > > Separately from this there's a problem with the user being unable to > know if the algorithm is going to fail because of

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 09:42:34 schrieb Andrew Zaborowski: Hi Andrew, > > > > I think we have agreed on dropping the length enforcement at the interface > > level. > > Separately from this there's a problem with the user being unable to > know if the algorithm is going to fail because of

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

Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša: Hi David, > Hello Stephan, > > Did you consider blocking urandom output or returning error until > initialized? Given the speed of initialization you report, it shouldn't > break any userspace apps while making sure that nobody uses

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

Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša: Hi David, > Hello Stephan, > > Did you consider blocking urandom output or returning error until > initialized? Given the speed of initialization you report, it shouldn't > break any userspace apps while making sure that nobody uses

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra Padasalagi: Hi Raveendra, > From: Jeff Garzik > > This patch adds the implementation of SHA3 algorithm > in software and it's based on original implementation > pushed in patch https://lwn.net/Articles/518415/ with >

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra Padasalagi: Hi Raveendra, > From: Jeff Garzik > > This patch adds the implementation of SHA3 algorithm > in software and it's based on original implementation > pushed in patch https://lwn.net/Articles/518415/ with > additional changes to

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 10:22:15 schrieb Mat Martineau: Hi Mat, > Stephan, > > On Sat, 14 May 2016, Tadeusz Struk wrote: > > From: Stephan Mueller <smuel...@chronox.de> > > > > This patch adds the user space interface for asymmetric ciphers. The > &

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 10:22:15 schrieb Mat Martineau: Hi Mat, > Stephan, > > On Sat, 14 May 2016, Tadeusz Struk wrote: > > From: Stephan Mueller > > > > This patch adds the user space interface for asymmetric ciphers. The > > interface allows the u

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski: Hi Andrew, > Hi, > > On 8 June 2016 at 21:14, Mat Martineau > > <mathew.j.martin...@linux.intel.com> wrote: > > On Wed, 8 Jun 2016, Stephan Mueller wrote: > >> What is your concern? > >

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 14. Juni 2016, 00:16:11 schrieb Andrew Zaborowski: Hi Andrew, > Hi, > > On 8 June 2016 at 21:14, Mat Martineau > > wrote: > > On Wed, 8 Jun 2016, Stephan Mueller wrote: > >> What is your concern? > > > > Userspace must allocate

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 13. Juni 2016, 11:48:37 schrieb Theodore Ts'o: Hi Theodore, > /* > @@ -1254,15 +1423,26 @@ static ssize_t extract_entropy_user(struct > entropy_store *r, void __user *buf, */ > void get_random_bytes(void *buf, int nbytes) > { > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > + > #if

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 13. Juni 2016, 11:48:37 schrieb Theodore Ts'o: Hi Theodore, > /* > @@ -1254,15 +1423,26 @@ static ssize_t extract_entropy_user(struct > entropy_store *r, void __user *buf, */ > void get_random_bytes(void *buf, int nbytes) > { > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > + > #if

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau: Hi Mat, Tadeusz, > On Thu, 9 Jun 2016, Stephan Mueller wrote: > > Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau: > > > > Hi Mat, > > > >>> Or is your concern that the user space in

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 9. Juni 2016, 11:27:13 schrieb Mat Martineau: Hi Mat, Tadeusz, > On Thu, 9 Jun 2016, Stephan Mueller wrote: > > Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau: > > > > Hi Mat, > > > >>> Or is your concern that the user space in

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau: Hi Mat, > > Or is your concern that the user space interface restricts things too much > > and thus prevents a valid use case? > > The latter - my primary concern is the constraint this places on userspace > by forcing larger buffer

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Donnerstag, 9. Juni 2016, 11:18:04 schrieb Mat Martineau: Hi Mat, > > Or is your concern that the user space interface restricts things too much > > and thus prevents a valid use case? > > The latter - my primary concern is the constraint this places on userspace > by forcing larger buffer

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Mittwoch, 8. Juni 2016, 12:14:49 schrieb Mat Martineau: Hi Mat, > On Wed, 8 Jun 2016, Stephan Mueller wrote: > > Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau: > > > > Hi Mat, > > > >>> + used = ctx->used; > >>> + > &g

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Mittwoch, 8. Juni 2016, 12:14:49 schrieb Mat Martineau: Hi Mat, > On Wed, 8 Jun 2016, Stephan Mueller wrote: > > Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau: > > > > Hi Mat, > > > >>> + used = ctx->used; > >>> + > &g

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau: Hi Mat, > > + used = ctx->used; > > + > > + /* convert iovecs of output buffers into scatterlists */ > > + while (iov_iter_count(>msg_iter)) { > > + /* make one iovec available as scatterlist */ > > + err =

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau: Hi Mat, > > + used = ctx->used; > > + > > + /* convert iovecs of output buffers into scatterlists */ > > + while (iov_iter_count(>msg_iter)) { > > + /* make one iovec available as scatterlist */ > > + err =

Re: authenc methods vs FIPS in light of unencrypted associated data

Am Donnerstag, 2. Juni 2016, 18:01:04 schrieb Marcus Meissner: Hi Marcus, Herbert > Hi, > > In February I already tagged some authenc ciphers for FIPS compatibility. > > I currently revisit this to get testmgr running all the tests in strict FIPS > mode. > > The authenc() class is

Re: authenc methods vs FIPS in light of unencrypted associated data

Am Donnerstag, 2. Juni 2016, 18:01:04 schrieb Marcus Meissner: Hi Marcus, Herbert > Hi, > > In February I already tagged some authenc ciphers for FIPS compatibility. > > I currently revisit this to get testmgr running all the tests in strict FIPS > mode. > > The authenc() class is

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

Add LRNG compilation support. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 1d33beb..9aaf96c 100644 --- a/crypto/Kconfig +++ b/crypto/K

[PATCH v4 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 <smuel...@chronox.de> --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 del

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

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 1d33beb..9aaf96c 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1588,6 +1588,16

[PATCH v4 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 v4 3/5] crypto: Linux Random Number Generator

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/lrng.c | 1981 + 1 file changed, 1981 insertions(+) create mode 100644 crypto/lrng.c diff --git a/

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

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller --- crypto/lrng.c | 1981 + 1 file changed, 1981 insertions(+) create mode 100644 crypto/lrng.c diff --git a/crypto/lrng.c b/crypto/lrng.c

[PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler

the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- drivers/char/random.c | 1 + drivers/hv/vmbus_drv.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/ra

[PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler

the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 + drivers/hv/vmbus_drv.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/char/random.c b/drivers/char/random.c index ef89c0e..ac74716

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

, 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 functions for LRNG random: conditionally compile code depending on LRNG crypto: Linux Random Number

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

-off-by: Stephan Mueller <smuel...@chronox.de> --- 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 0158d3b..ef89c0e

[PATCH v4 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 0158d3b..ef89c0e 100644 --- a/drivers/char

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

, 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 functions for LRNG random: conditionally compile code depending on LRNG crypto: Linux Random Number

Re: [PATCH 2/5] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 30. Mai 2016, 01:39:22 schrieb Theodore Ts'o: Hi Theodore, > On a system with a 4 socket (NUMA) system where a large number of > application threads were all trying to read from /dev/urandom, this > can result in the system spending 80% of its time contending on the > global urandom

Re: [PATCH 2/5] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 30. Mai 2016, 01:39:22 schrieb Theodore Ts'o: Hi Theodore, > On a system with a 4 socket (NUMA) system where a large number of > application threads were all trying to read from /dev/urandom, this > can result in the system spending 80% of its time contending on the > global urandom

Re: [PATCH v6 0/6] crypto: algif - add akcipher

Am Samstag, 14. Mai 2016, 21:16:45 schrieb Tadeusz Struk: Hi Tadeusz, > First four patches are a resend of the v3 algif_akcipher from > Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. All four patches from me: Acked-by: Stephan Mueller <smuel...@chronox.de> Ciao Stephan

Re: [PATCH v6 0/6] crypto: algif - add akcipher

Am Samstag, 14. Mai 2016, 21:16:45 schrieb Tadeusz Struk: Hi Tadeusz, > First four patches are a resend of the v3 algif_akcipher from > Stephan Mueller, with minor changes after rebase on top of 4.6-rc1. All four patches from me: Acked-by: Stephan Mueller Ciao Stephan

Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

Am Donnerstag, 5. Mai 2016, 12:51:20 schrieb Tadeusz Struk: Hi Tadeusz, > This patch adds support for asymmetric key type to AF_ALG. > It will work as follows: A new PF_ALG socket options are > added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely > ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID

Re: [PATCH RESEND v5 6/6] crypto: AF_ALG - add support for key_id

Am Donnerstag, 5. Mai 2016, 12:51:20 schrieb Tadeusz Struk: Hi Tadeusz, > This patch adds support for asymmetric key type to AF_ALG. > It will work as follows: A new PF_ALG socket options are > added on top of existing ALG_SET_KEY and ALG_SET_PUBKEY, namely > ALG_SET_KEY_ID and ALG_SET_PUBKEY_ID

Re: [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API

Am Donnerstag, 5. Mai 2016, 12:50:54 schrieb Tadeusz Struk: Hi Tadeusz, David, > From: Stephan Mueller <smuel...@chronox.de> > > Add the flags for handling signature generation and signature > verification. > > Also, the patch adds the interface for setting a pub

Re: [PATCH RESEND v5 1/6] crypto: AF_ALG -- add sign/verify API

Am Donnerstag, 5. Mai 2016, 12:50:54 schrieb Tadeusz Struk: Hi Tadeusz, David, > From: Stephan Mueller > > Add the flags for handling signature generation and signature > verification. > > Also, the patch adds the interface for setting a public key. > > Signed

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c |

Re: [PATCH 1/4] random: replace non-blocking pool with a Chacha20-based CRNG

Am Mittwoch, 4. Mai 2016, 15:25:48 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c | 283 >

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Dienstag, 3. Mai 2016, 11:36:12 schrieb Stephan Mueller: Hi Ted, > > + > > +static ssize_t extract_crng_user(void __user *buf, size_t nbytes) > > +{ > > + ssize_t ret = 0, i; > > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > > + int large_request = (nbytes

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Dienstag, 3. Mai 2016, 11:36:12 schrieb Stephan Mueller: Hi Ted, > > + > > +static ssize_t extract_crng_user(void __user *buf, size_t nbytes) > > +{ > > + ssize_t ret = 0, i; > > + __u8 tmp[CHACHA20_BLOCK_SIZE]; > > + int large_request = (nbytes

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, One more item. > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- >

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, One more item. > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 -- > drivers/char/random.c | 282

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. In general, I have no concerns with this approach either. And thank you that some of my concerns are addressed. There are few more

Re: [PATCH 1/3] random: replace non-blocking pool with a Chacha20-based CRNG

Am Montag, 2. Mai 2016, 02:26:51 schrieb Theodore Ts'o: Hi Theodore, > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. In general, I have no concerns with this approach either. And thank you that some of my concerns are addressed. There are few more

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 09:48:57 schrieb Theodore Ts'o: Hi Theodore, > On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > > - entropy pool draining: when having a timer-based reseeding on a quiet > > > system, the entropy pool can be drained during the expiry of the timer. > > >

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 09:48:57 schrieb Theodore Ts'o: Hi Theodore, > On Mon, May 02, 2016 at 08:50:14AM -0400, Theodore Ts'o wrote: > > > - entropy pool draining: when having a timer-based reseeding on a quiet > > > system, the entropy pool can be drained during the expiry of the timer. > > >

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

Am Montag, 2. Mai 2016, 05:00:47 schrieb Jeffrey Walton: Hi Jeffrey, > On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o <ty...@mit.edu> wrote: > > From: Stephan Mueller <smuel...@chronox.de> > > > > The Hyper-V Linux Integration Services use the VMBus imp

Re: [PATCH 3/3] random: add interrupt callback to VMBus IRQ handler

Am Montag, 2. Mai 2016, 05:00:47 schrieb Jeffrey Walton: Hi Jeffrey, > On Mon, May 2, 2016 at 2:26 AM, Theodore Ts'o wrote: > > From: Stephan Mueller > > > > The Hyper-V Linux Integration Services use the VMBus implementation for > > communication with the Hypervis

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o: Hi Theodore, I have not digested the patch set yet, but I have the following questions to your patch set. > On a system with a 4 socket (NUMA) system where a large number of > application processes were all trying to read from

Re: [PATCH 2/3] random: make /dev/urandom scalable for silly userspace programs

Am Montag, 2. Mai 2016, 02:26:52 schrieb Theodore Ts'o: Hi Theodore, I have not digested the patch set yet, but I have the following questions to your patch set. > On a system with a 4 socket (NUMA) system where a large number of > application processes were all trying to read from

Re: random(4) changes

Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin: Hi George, > > What I am saying that the bits in one given time stamp are mutually > > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > > very same time stamp. > > And I'm saying that's wrong. I think we

Re: random(4) changes

Am Freitag, 29. April 2016, 16:08:48 schrieb George Spelvin: Hi George, > > What I am saying that the bits in one given time stamp are mutually > > independent. I.e. bit 0 of one time stamp does not depend on bit 1 of that > > very same time stamp. > > And I'm saying that's wrong. I think we

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

Re: random(4) changes

Am Freitag, 29. April 2016, 14:02:48 schrieb George Spelvin: Hi George, > >> 1. It DOES depend on the attacker. Any statement about independence > >> > >>depends on the available knowledge. > >> > >> 2. XOR being entropy preserving depends on independence ONLY, it does > >> > >>NOT

Re: random(4) changes

Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin: Hi George, > > I think there is a slight mixup: IID is not related to an attacker > > predicting things. IID is simply a statistical measure, it is either there > > or not. It does not depend on an attacker (assuming that the attacker

Re: random(4) changes

Am Freitag, 29. April 2016, 07:04:24 schrieb George Spelvin: Hi George, > > I think there is a slight mixup: IID is not related to an attacker > > predicting things. IID is simply a statistical measure, it is either there > > or not. It does not depend on an attacker (assuming that the attacker

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: Hi Richard, > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > Signed-off-by: Richard W.M. Jones > --- >

Re: [PATCH] crypto: Add a flag allowing the self-tests to be disabled at runtime.

Am Freitag, 29. April 2016, 11:07:43 schrieb Richard W.M. Jones: Hi Richard, > Running self-tests for a short-lived KVM VM takes 28ms on my laptop. > This commit adds a flag 'cryptomgr.notests' which allows them to be > disabled. > > Signed-off-by: Richard W.M. Jones > --- >

Re: random(4) changes

Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin: Hi George, > (Note that we have two chains of e-mails crossing mid-stream. I'm in > the middle of working on a much longer reply to your previous e-mail.) > > >> They're not independent, nor are they identically distributed. > > > >

Re: random(4) changes

Am Freitag, 29. April 2016, 05:34:18 schrieb George Spelvin: Hi George, > (Note that we have two chains of e-mails crossing mid-stream. I'm in > the middle of working on a much longer reply to your previous e-mail.) > > >> They're not independent, nor are they identically distributed. > > > >

Re: random(4) changes

Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin: Hi George, > > 1. the individual bits of a given 32 bit time stamp are independent > > > >(or IID in terms of NIST) > > They're not independent, nor are they identically distributed. That is an interesting statement: you say

Re: random(4) changes

Am Freitag, 29. April 2016, 03:29:50 schrieb George Spelvin: Hi George, > > 1. the individual bits of a given 32 bit time stamp are independent > > > >(or IID in terms of NIST) > > They're not independent, nor are they identically distributed. That is an interesting statement: you say

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

Add LRNG compilation support. Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 93a1fdc..938f2dc 100644 --- a/crypto/Kconfig +++ b/crypto/K

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

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 93a1fdc..938f2dc 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1587,6 +1587,16

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

>From 443dd61dcf2cf5a7a516c552da463ee2d8aea949 Mon Sep 17 00:00:00 2001 From: Stephan Mueller <smuel...@chronox.de> Date: Mon, 18 Apr 2016 10:04:33 +0200 Subject: This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by

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

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- crypto/lrng.c | 1914 + 1 file changed, 1914 insertions(+) create mode 100644 crypto/lrng.c diff --git a/

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

>From 443dd61dcf2cf5a7a516c552da463ee2d8aea949 Mon Sep 17 00:00:00 2001 From: Stephan Mueller Date: Mon, 18 Apr 2016 10:04:33 +0200 Subject: 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 --- cry

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

with the legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller --- crypto/lrng.c | 1914 + 1 file changed, 1914 insertions(+) create mode 100644 crypto/lrng.c diff --git a/crypto/lrng.c b/crypto/lrng.c

[PATCH v3 5/5] random: add interrupt callback to VMBus IRQ handler

the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by: Stephan Mueller <stephan.muel...@atsec.com> Signed-off-by: Stephan Mueller <smuel...@chronox.de> --- drivers/char/random.c | 1 + drivers/hv/vmbus_drv.c | 3 +++ 2 files changed,

[PATCH v3 5/5] random: add interrupt callback to VMBus IRQ handler

the interrupt entropy collection callback into the VMBus interrupt handler function. Signed-off-by: Stephan Mueller Signed-off-by: Stephan Mueller --- drivers/char/random.c | 1 + drivers/hv/vmbus_drv.c | 3 +++ 2 files changed, 4 insertions(+) diff --git a/drivers/char/random.c b/drivers/char

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

mons. 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 functions for LRN

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

-off-by: Stephan Mueller <smuel...@chronox.de> --- 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 b583e53..92c2174

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

mons. 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 functions for LRN

[PATCH v3 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 b583e53..92c2174 100644 --- a/drivers/char

Re: random(4) changes

Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin: Hi George, > > And considering that I only want to have 0.9 bits of entropy, why > > should I not collapse it? The XOR operation does not destroy the existing > > entropy, it only caps it to at most one bit of information theoretical

Re: random(4) changes

Am Dienstag, 26. April 2016, 20:23:46 schrieb George Spelvin: Hi George, > > And considering that I only want to have 0.9 bits of entropy, why > > should I not collapse it? The XOR operation does not destroy the existing > > entropy, it only caps it to at most one bit of information theoretical

Re: random(4) changes

Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen: Hi Andi, > > > > If it is the latter, can you explain where the scalability issue comes > > > > in? > > > > > > A single pool which is locked/written to does not scale. Larger systems > > > need multiple pools > > > > That would imply

Re: random(4) changes

Am Montag, 25. April 2016, 12:35:32 schrieb Andi Kleen: Hi Andi, > > > > If it is the latter, can you explain where the scalability issue comes > > > > in? > > > > > > A single pool which is locked/written to does not scale. Larger systems > > > need multiple pools > > > > That would imply

<    1   2   3   4   5   6   7   8   9   10   >