Re: [PATCH v6] security/keys: rewrite all of big_key crypto

Am Mittwoch, 20. September 2017, 12:52:21 CEST schrieb Jason A. Donenfeld: Hi Jason, > > This sounds incorrect to me. Choosing a fresh, random, one-time-use > 256-bit key and rolling with a zero nonce is a totally legitimate way > of using GCM. There's no possible reuse of the key stream this w

Re: [PATCH v6] security/keys: rewrite all of big_key crypto

Am Sonntag, 17. September 2017, 13:52:17 CEST schrieb Jason A. Donenfeld: Hi Jason, > * Use of ECB mode, allowing an attacker to trivially swap blocks or > compare identical plaintext blocks. The use of GCM with the implementtion here is just as challenging. The implementation uses a NULL

Re: [kernel-hardening] Re: [PATCH v4] security/keys: rewrite all of big_key crypto

Am Montag, 18. September 2017, 11:04:55 CEST schrieb Greg KH: Hi Greg, > On Mon, Sep 18, 2017 at 10:49:56AM +0200, Stephan Mueller wrote: > > Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld: > > > > Hi Jason, > > > > > This star

Re: [PATCH v4] security/keys: rewrite all of big_key crypto

Am Samstag, 16. September 2017, 15:00:34 CEST schrieb Jason A. Donenfeld: Hi Jason, > This started out as just replacing the use of crypto/rng with > get_random_bytes_wait, This change is a challenge. The use of the kernel crypto API's DRNG has been made to allow FIPS 140-2 compliance. Otherwi

Re: [BUGFIX PATCH v2] staging: ccree: save ciphertext for CTS IV

Am Mittwoch, 23. August 2017, 12:47:36 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > Thank you for your persistence. It is appreciated :-) > > If I understood correctly what you are referring to than the buffer is not > allocated in this code path (unless I've missed something): Ah, that is what

Re: [BUGFIX PATCH v2] staging: ccree: save ciphertext for CTS IV

d with cts(cbc(aes)) mode in tcrypt tests. > > Fixes: 302ef8ebb4b2 ("Add CryptoCell skcipher support") > Signed-off-by: Gilad Ben-Yossef > --- > > Changes from v1: > - Free memory on error path, as pointed out by Stephan Mueller. > > drivers/staging/ccree/ssi_c

Re: [BUGFIX PATCH] staging: ccree: save ciphertext for CTS IV

Am Mittwoch, 23. August 2017, 09:41:11 CEST schrieb Gilad Ben-Yossef: Hi Gilad, > > if (areq) { > + /* > + * The crypto API expects us to set the req->info to the last > + * ciphertext block. For encrypt, simply copy from the result. > + *

Re: random.c: LFSR polynomials are not irreducible/primitive

Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o: Hi Theodore, Jeffrey, > > Stephan, if you have any comments on the proposal made by David > Fontaine and Olivier Vivolo, I'd appreciate hearing them! (from Jefferey): > This may be helpful, too. I use it to look up minimal weigh

Re: random.c: LFSR polynomials are not irreducible/primitive

Am Dienstag, 15. August 2017, 17:12:24 CEST schrieb Theodore Ts'o: Hi Theodore, > > Stephan, if you have any comments on the proposal made by David > Fontaine and Olivier Vivolo, I'd appreciate hearing them! I think I have some news: The magma code I used for GF(2^32) testing was not correct.

Re: [PATCH] crypto: mediatek - Add empty messages check in GCM mode

Am Mittwoch, 16. August 2017, 13:19:48 CEST schrieb Ryder Lee: Hi Ryder, > Currently, empty messages are not supported in GCM mode, hence add > a check to prevent producing incorrect results. In case the caller would provide empty messages, would there be just wrong data or a real problem? Note

Re: random.c: LFSR polynomials are not irreducible/primitive

Am Dienstag, 15. August 2017, 00:21:05 CEST schrieb Theodore Ts'o: Hi Theodore, > Have you looked at section 3.1.1 of the above cited paper? > > http://eprint.iacr.org/2012/251.pdf Thanks for the hint, but that does not seem to solve the mystery either. When I use magma with GF(2^32), I

random.c: LFSR polynomials are not irreducible/primitive

Hi Ted, drivers/char/random.c contains the following comment: """ * Our mixing functions were analyzed by Lacharme, Roeck, Strubel, and * Videau in their paper, "The Linux Pseudorandom Number Generator * Revisited" (see: http://eprint.iacr.org/2012/251.pdf). In their * paper, they point out

Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG

Am Donnerstag, 17. November 2016, 09:07:48 CET schrieb Corentin Labbe: Hi Corentin, > > Seed again, or just do not seed (and so return -EAGAIN for read() function) > until ready_callback ? This is your choice. But for the start sequence, you should not simply rely on get_random_bytes. For the

Re: why getrandom blocking does not work with /dev/urandom

Am Samstag, 22. Oktober 2016, 01:10:26 CEST schrieb Theodore Ts'o: Hi Theodore, > In any case, yes, you're not telling me anything I didn't know. What > I didn't know and still don't know is *why* systemd is tryinig to read > from /dev/urandom. e.g., is it trying to initialize cryptographic > k

[ANNOUNCE] /dev/random - a new approach code for 4.9-rc1

Hi, The patch set that can be downloaded at [1] provides a different approach to / dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time a

why getrandom blocking does not work with /dev/urandom

Hi Ted, as mentioned, I looked a bit deeper into the issue of adding the blocking behavior of getrandom to /dev/urandom. As you and I already identified, moving that blocking behavior to /dev/urandom simply does not work. The system does not boot. The reason to this issue is actually quite sim

Re: [PATCH] crypto: sun4i-ss: support the Security System PRNG

Am Dienstag, 18. Oktober 2016, 14:34:27 CEST schrieb Corentin Labbe: Hi Corentin, > diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c > b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c new file mode 100644 > index 000..95fadb7 > --- /dev/null > +++ b/drivers/crypto/sunxi-ss/sun4i-ss-hwrng.c > @

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 14:03:17 CEST schrieb Andy Lutomirski: Hi Andy, > On Mon, Oct 17, 2016 at 11:36 AM, Stephan Mueller wrote: > > Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: > > > > Hi Andy, > > > >> Sure, but shouldn

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 10:30:13 CEST schrieb Andy Lutomirski: Hi Andy, > > Sure, but shouldn't that be a separate patch covering the whole hw_crypto > core? I think that you are right -- there are many more cases where a memset(0) is warranted. Do you want to make this change or should I

Re: [PATCH resend 4.9] hw_random: Don't use a stack buffer in add_early_randomness()

Am Montag, 17. Oktober 2016, 10:06:27 CEST schrieb Andy Lutomirski: Hi Andy, > diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c > index 9203f2d130c0..340f96e44642 100644 > --- a/drivers/char/hw_random/core.c > +++ b/drivers/char/hw_random/core.c > @@ -84,14 +84,14 @@ sta

Re: [PATCH 1/1] crypto: atmel-aes: add support to the XTS mode

Am Donnerstag, 29. September 2016, 18:49:07 CEST schrieb Cyrille Pitchen: Hi Cyrille, > This patch adds the xts(aes) algorithm, which is supported from > hardware version 0x500 and above (sama5d2x). > > Signed-off-by: Cyrille Pitchen > --- > drivers/crypto/atmel-aes-regs.h | 4 + > drivers/c

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

Am Dienstag, 27. September 2016, 16:44:16 CEST schrieb Kalle Valo: Hi Kalle, > Stephan Mueller wrote: > > The ATH9K driver implements an RNG which is completely bypassing the > > standard Linux HW generator logic. > > > > The RNG may or may not deliver entropy. C

Re: [PATCH] security/keys: make BIG_KEYS dependent on stdrng.

Am Dienstag, 6. September 2016, 14:11:56 CEST schrieb David Howells: Hi David, > Artem Savkov wrote: > > > > - select CRYPTO > > > > + depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y) > > > > > > Should those be "==" not "="? > > > > Accodring to Documentation/kbuild/kconfig-l

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] KEYS: fix big_key dependency

Am Dienstag, 16. August 2016, 00:45:39 CEST schrieb Kirill Marinushkin: Hi Kirill, > + select CRYPTO_ANSI_CPRNG This change enables the RNG which will not pass FIPS testing any more. Hence, this selection could cause an issue in FIPS mode (i.e. booting the kernel with fips=1). May I sugge

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 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 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: [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

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

[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

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-kernel@vger.kernel.org

[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: [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

[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: [PATCH] KEYS: x86_64 needs to use compat_sys_keyctl for 32-bit userspace

Am Mittwoch, 27. Juli 2016, 11:42:38 CEST schrieb David Howells: Hi David, > x86_64 needs to use compat_sys_keyctl for 32-bit userspace rather than > calling sys_keyctl. The latter will work in a lot of cases, thereby hiding > the issue. > > Reported-by: Stephan Mueller > Si

Re: [PATCH 2/2] crypto: vmx - Adding support for XTS

Am Montag, 11. Juli 2016, 16:07:40 CEST schrieb Paulo Flabiano Smorigo: Hi Paulo, > From: "Leonidas S. Barbosa" > > This patch add XTS support using VMX-crypto driver. > > Signed-off-by: Leonidas S. Barbosa > Signed-off-by: Paulo Flabiano Smorigo > --- > drivers/crypto/vmx/Makefile | 2 +

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

Am Sonntag, 26. Juni 2016, 20:47:43 schrieb Pavel Machek: Hi Pavel, > Hi! > > > Yes, I understand the argument that the networking stack is now > > requiring the crypto layer --- but not all IOT devices may necessarily > > require the IP stack (they might be using some alternate wireless > > com

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

Am Donnerstag, 23. Juni 2016, 15:55:26 schrieb Tadeusz Struk: Hi Tadeusz, > First four patches are a resend algif_akcipher from > Stephan Mueller, with minor changes after rebase on top of 4.7-rc1. The first four patches: Acked-by: Stephan Mueller Ciao Stephan

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

Am Mittwoch, 22. Juni 2016, 15:45:38 schrieb Mat Martineau: Hi Mat, > > > > Ok, I'll update the patch. > > Thanks, that helps (especially with pkcs1pad). Tadeusz received the updated patch from me to integrate it into his patch set. > > This brings me to another proposal for read buffer sizin

[PATCH v2] crypto: Jitter RNG - use ktime_get_ns as fallback

((time2 - time)); Signed-off-by: Stephan Mueller --- crypto/jitterentropy-kcapi.c | 22 +- 1 file changed, 13 insertions(+), 9 deletions(-) diff --git a/crypto/jitterentropy-kcapi.c b/crypto/jitterentropy-kcapi.c index 597cedd..be1577c 100644 --- a/crypto/jitterentropy-kcapi

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

Am Mittwoch, 22. Juni 2016, 08:54:16 schrieb Austin S. Hemmelgarn: Hi Austin, > You're not demonstrating it's inherently present in the architecture, I am not demonstrating it, interesting statement. I take different arches from different vendors which were developed independently from each oth

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

Am Dienstag, 21. Juni 2016, 15:31:07 schrieb Austin S. Hemmelgarn: Hi Austin, > > Little data, interesting statement for results on 200+ systems including > > all major CPU arches all showing information leading in the same > > directions. > Let me try rephrasing this to make it a bit clearer: >

Re: [PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: Hi John, > I don't see in the above an explanation of *why* you're using > ktime_get_raw_ns() instead of ktime_get_ns(). Could you help me understand what the difference is or point me to some documentation? I understood that we only tal

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 14:22:48 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 12:28, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >> On 2016-06-21 03:32, Stephan Muelle

[PATCH] crypto: Jitter RNG - use ktime_get_raw_ns as fallback

execution time of the heart of the RNG: jent_get_nstime(&time); jent_memaccess(ec, min); jent_fold_time(NULL, time, &folded, min); jent_get_nstime(&time2); return ((time2 - time)); Signed-off-by: Stephan Mueller --- crypto/jitterentropy-

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

Am Dienstag, 21. Juni 2016, 13:51:15 schrieb Austin S. Hemmelgarn: Hi Austin, > > >> 2. Quite a few systems have a rather distressingly low lower bound and > >> still get accepted by your algorithm (a number of the S/390 systems, and > >> a handful of the AMD processors in particular). > > > >

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

Am Dienstag, 21. Juni 2016, 13:54:13 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 13:23, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >>> You have to trust the host fo

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 18:51:32 schrieb Stephan Mueller: Hi, > > So.. again, I'd avoid using the "fast" accessor unless there is a > > clear need or obvious benefit. Which should be documented. > > So, you suggest ktime_get_raw_ns? If yes, let me test

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

Am Dienstag, 21. Juni 2016, 13:18:33 schrieb Austin S. Hemmelgarn: Hi Austin, > > You have to trust the host for anything, not just for the entropy in > > timings. This is completely invalid argument unless you can present a > > method that one guest can manipulate timings in other guest in such

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:12:24 schrieb John Stultz: Hi John, > > So this is definitely more clear then what was described earlier, and > worries me because on many x86 machines (though fewer I guess these > days then in the past) the clocksource will often not be the TSC (and > have lower r

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:47:23 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 9:34 AM, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: > > > > Hi John, > > > >> On Tue, Jun 21, 2016 at 1:32 AM, Arnd Berg

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 09:22:31 schrieb John Stultz: Hi John, > On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann wrote: > > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > >> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > >

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 12:03:56 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-21 03:32, Stephan Mueller wrote: > > Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: > > > > Hi Nikos, > > > >> On Mon, Jun 20, 2016 at 5:43

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

Am Dienstag, 21. Juni 2016, 09:05:55 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-20 14:32, Stephan Mueller wrote: > > Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: > > > > Hi Austin, > > > >> On 2016-06-18 12:31, Stephan Muell

Re: [PATCH] crypto: use timespec64 for jent_get_nstime

Am Dienstag, 21. Juni 2016, 10:32:23 schrieb Arnd Bergmann: Hi Arnd, > On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > > > > Hi Arnd, > > > > > The jent_get_nstime() fun

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 09:12:07 schrieb Nikos Mavrogiannopoulos: Hi Nikos, > On Mon, Jun 20, 2016 at 5:43 PM, Stephan Mueller wrote: > >> Personally, I don't really use /dev/random, nor would I recommend it > >> for most application programmers. At this point, g

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 __getn

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Dienstag, 21. Juni 2016, 01:12:55 schrieb Theodore Ts'o: Hi Theodore, > On Mon, Jun 20, 2016 at 09:00:49PM +0200, Stephan Mueller wrote: > > The time stamp maintenance is the exact cause for the correlation: one HID > > event triggers: > > > > - add_interrupt

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Montag, 20. Juni 2016, 14:44:03 schrieb George Spelvin: Hi George, > > With that being said, wouldn't it make sense to: > > > > - Get rid of the entropy heuristic entirely and just assume a fixed value > > of entropy for a given event? > > What does that gain you? You can always impose an u

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

Am Montag, 20. Juni 2016, 13:07:32 schrieb Austin S. Hemmelgarn: Hi Austin, > On 2016-06-18 12:31, Stephan Mueller wrote: > > Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o: > > > > Hi Theodore, > > > >> At the end of the day, with these devi

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

Am Montag, 20. Juni 2016, 11:01:47 schrieb Theodore Ts'o: Hi Theodore, > > So simply doing chacha20 encryption in a tight loop in the kernel > might not be a good proxy for what would actually happen in real life > when someone calls getrandom(2). (Another good question to ask is > when someone

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Montag, 20. Juni 2016, 11:28:38 schrieb Theodore Ts'o: Hi Theodore, > On Mon, Jun 20, 2016 at 07:51:59AM +0200, Stephan Mueller wrote: > > - Correlation of noise sources: as outlined in [1] chapter 1, the three > > noise sources of the legacy /dev/random implem

Re: [PATCH v5 0/7] /dev/random - a new approach

Am Sonntag, 19. Juni 2016, 21:36:14 schrieb Pavel Machek: Hi Pavel, > On Sun 2016-06-19 17:58:41, Stephan Mueller wrote: > > Hi Herbert, Ted, > > > > The following patch set provides a different approach to /dev/random which > > I call Linux Random Number Generato

Re: [PATCH v5 3/7] crypto: Linux Random Number Generator

Am Sonntag, 19. Juni 2016, 09:58:55 schrieb Andi Kleen: Hi Andi, > On Sun, Jun 19, 2016 at 06:00:21PM +0200, Stephan Mueller wrote: > > The LRNG with all its properties is documented in [1]. This > > documentation covers the functional discussion as well as testing of all > &g

[PATCH v5 4/7] crypto: LRNG - enable compile

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 v5 2/7] 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 v5 1/7] 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 v5 3/7] crypto: Linux Random Number Generator

legacy /dev/random implementation. [1] http://www.chronox.de/lrng.html Signed-off-by: Stephan Mueller --- crypto/lrng_base.c | 1942 +++ crypto/lrng_kcapi.c | 167 + 2 files changed, 2109 insertions(+) create mode 100644 crypto/lrng_base.c

[PATCH v5 4/7] 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 c903f18..772d430 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1589,6 +1589,17

[PATCH v5 0/7] /dev/random - a new approach

32 bit and MIPS 32 bit. [1] http://www.chronox.de/lrng/doc/lrng.pdf [2] http://www.chronox.de/lrng.html Stephan Mueller (7): crypto: DRBG - externalize DRBG functions for LRNG random: conditionally compile code depending on LRNG crypto: Linux Random Number Generator crypto: LRNG - enable

[PATCH v5 7/7] crypto: LRNG - add ChaCha20 support

In case the kernel crypto API is not compiled, use ChaCha20 stream cipher as DRNG. The LRNG ChaCha20 support provides the DRNG implementation with the generate and update functions. Further documentation is provided in [1]. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 2

[PATCH v5 6/7] crypto: isolate the chacha20_block function

The chacha20_block function is extracted into its separate C file to allow it to be used by other callers. Signed-off-by: Stephan Mueller --- crypto/Kconfig| 4 +++ crypto/Makefile | 1 + crypto/chacha20_block.c | 79

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

Am Samstag, 18. Juni 2016, 10:44:08 schrieb Theodore Ts'o: Hi Theodore, > > At the end of the day, with these devices you really badly need a > hardware RNG. We can't generate randomness out of thin air. The only > thing you really can do requires user space help, which is to generate > keys l

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) wou

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 __getn

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, 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-b

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 e

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 :-) ), bec

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 d

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 predic

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 m

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 use

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 larg

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 DEBUG_R

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 si

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

[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

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

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