Re: drivers/char/random.c needs a (new) maintainer

Pavel Machek wrote: > To play devil's advocate, does RNG subsystem need to evolve? Its task > is to get random numbers. Does it fail at the task? > > Problem is, random subsystem is hard to verify, and big rewrite is > likely to cause security problems... Parts of the problem, though, are dead

Re: Looking for an open-source thesis idea

Eric Curtin wrote: > Hope I'm not bothering you. I'm looking for a masters thesis idea, ... Here's a report claiming 70% of security bugs involve memory errors. https://www.zdnet.com/article/chrome-70-of-all-security-bugs-are-memory-safety-issues/ Build a tool to find or fix those? Another

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

On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude

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

On Tue, Sep 19, 2017 at 9:39 AM, Theodore Ts'o wrote: > On Mon, Sep 18, 2017 at 01:24:18PM +0200, Jason A. Donenfeld wrote: >> Good luck with getting approval... While Ted and I have our >> differences like any two kernel developers, I really tend agree with >> him in his attitude about this

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Sandy Harris <sandyinch...@gmail.com> wrote: > The biggest problem with random(4) is that you cannot generate good > output without a good seed & just after boot, ... > > The only really good solution I know of is to find a way to provide a > chunk of randomness early

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

Sandy Harris wrote: > The biggest problem with random(4) is that you cannot generate good > output without a good seed & just after boot, ... > > The only really good solution I know of is to find a way to provide a > chunk of randomness early in the boot process. Joh

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 5:08 PM, Theodore Ts'o wrote: > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. A good approach. > Things that I've chosen not take is basically because I disbelieve > that the

Re: [RFC PATCH v12 3/4] Linux Random Number Generator

On Tue, Jul 18, 2017 at 5:08 PM, Theodore Ts'o wrote: > I've been trying to take the best features and suggestions from your > proposal and integrating them into /dev/random already. A good approach. > Things that I've chosen not take is basically because I disbelieve > that the Jitter RNG is

Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton wrote: > On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote: >> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: >>> > Suppressing all messages for all configurations cast a wider net than

Re: [kernel-hardening] Re: [PATCH] random: silence compiler warnings and fix race

On Tue, Jun 20, 2017 at 5:49 AM, Jeffrey Walton wrote: > On Tue, Jun 20, 2017 at 5:36 AM, Theodore Ts'o wrote: >> On Tue, Jun 20, 2017 at 10:53:35AM +0200, Jason A. Donenfeld wrote: >>> > Suppressing all messages for all configurations cast a wider net than >>> > necessary. Configurations that

Re: get_random_bytes returns bad randomness before seeding is complete

at https://github.com/sandy-harris/maxwell The only kernel-space code I know of is Stephan's. If the claim that such calls give entropy is accepted (which I think it should be) then if we get one bit per call, need 100 or so bits & space the calls 100 ns apart, loading up a decent chunk of startup entropy

Re: get_random_bytes returns bad randomness before seeding is complete

at https://github.com/sandy-harris/maxwell The only kernel-space code I know of is Stephan's. If the claim that such calls give entropy is accepted (which I think it should be) then if we get one bit per call, need 100 or so bits & space the calls 100 ns apart, loading up a decent chunk of startup entropy

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

The only sensible & general solution for the initialisation problem that I have seen is John Denker's. http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image If I read that right, it would require only minor kernel changes & none to the API Ted & others are worrying about. It would be

Re: [kernel-hardening] Re: get_random_bytes returns bad randomness before seeding is complete

The only sensible & general solution for the initialisation problem that I have seen is John Denker's. http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image If I read that right, it would require only minor kernel changes & none to the API Ted & others are worrying about. It would be

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

Add Ted T'so to cc list. Shouldn't he be included on anything affecting the random(4) driver? On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe wrote: > From: LABBE Corentin > > The Security System have a PRNG. > This patch add support for it

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

Add Ted T'so to cc list. Shouldn't he be included on anything affecting the random(4) driver? On Tue, Oct 18, 2016 at 8:34 AM, Corentin Labbe wrote: > From: LABBE Corentin > > The Security System have a PRNG. > This patch add support for it as an hwrng. Which is it? A PRNG & a HW RNG are

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Wed, Nov 2, 2016 at 4:09 PM, Herbert Xu wrote: > On Wed, Nov 02, 2016 at 06:58:10PM +0100, Jason A. Donenfeld wrote: >> On MIPS chips commonly found in inexpensive routers, this makes a big >> difference in performance. >> >> Signed-off-by: Jason A. Donenfeld

Re: [PATCH] poly1305: generic C can be faster on chips with slow unaligned access

On Wed, Nov 2, 2016 at 4:09 PM, Herbert Xu wrote: > On Wed, Nov 02, 2016 at 06:58:10PM +0100, Jason A. Donenfeld wrote: >> On MIPS chips commonly found in inexpensive routers, this makes a big >> difference in performance. >> >> Signed-off-by: Jason A. Donenfeld > > Can you give some numbers

Re: Entropy sources (was: /dev/random - a new approach)

-hpa One possible solution is at: https://github.com/sandy-harris/maxwell A small (< 700 lines) daemon that gets entropy from timer imprecision and variations in time for arithmetic (cache misses, interrupts, etc.) and pumps it into /dev/random. Make it the first userspace program started a

Re: Entropy sources (was: /dev/random - a new approach)

on is at: https://github.com/sandy-harris/maxwell A small (< 700 lines) daemon that gets entropy from timer imprecision and variations in time for arithmetic (cache misses, interrupts, etc.) and pumps it into /dev/random. Make it the first userspace program started and all should be covere

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

Jason Cooper wrote: > Modern systems that receive a seed from the bootloader via the > random-seed property (typically from the hw-rng) can mix both sources > for increased resilience. > > Unfortunately, I'm not very familiar with the internals of x86 > bootstrapping.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

Jason Cooper wrote: > Modern systems that receive a seed from the bootloader via the > random-seed property (typically from the hw-rng) can mix both sources > for increased resilience. > > Unfortunately, I'm not very familiar with the internals of x86 > bootstrapping. Could GRUB be scripted to

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

On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek wrote: >> The following patch set provides a different approach to /dev/random ... > > Dunno. It is very similar to existing rng, AFAICT. I do not think so. A lot of the basic principles are the same of course, but Stephan is

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

On Sun, Jun 19, 2016 at 3:36 PM, Pavel Machek wrote: >> The following patch set provides a different approach to /dev/random ... > > Dunno. It is very similar to existing rng, AFAICT. I do not think so. A lot of the basic principles are the same of course, but Stephan is suggesting some real

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

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) wouldn't it help for large urandom consumers if kernel created

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

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) wouldn't it help for large urandom consumers if kernel created a DRBG > instance

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

, not just a single word like a pointer, but there's clearly > people around who have tried to search for good hashes that really > spread out the bits. > > Linus Here's another possibility, from my GPL code at: https://github.com/sandy-harris/maxwell Not very efficient -- two

Re: [patch 2/7] lib/hashmod: Add modulo based hash mechanism

but there's clearly > people around who have tried to search for good hashes that really > spread out the bits. > > Linus Here's another possibility, from my GPL code at: https://github.com/sandy-harris/maxwell Not very efficient -- two each of 32-bit multiply & modul

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > Instead of arguing over who's "sane" or "insane", can we come up with > a agreed upon set of tests, and a set of compiler and compiler > versions ... I completely fail to see why tests or compiler versions should be part of

Re: better patch for linux/bitops.h

On Wed, May 4, 2016 at 11:50 PM, Theodore Ts'o wrote: > Instead of arguing over who's "sane" or "insane", can we come up with > a agreed upon set of tests, and a set of compiler and compiler > versions ... I completely fail to see why tests or compiler versions should be part of the discussion.

Re: random(4) changes

On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen <a...@firstfloor.org> wrote: > Sandy Harris <sandyinch...@gmail.com> writes: > > There is also the third problem of horrible scalability of /dev/random > output on larger systems, for which patches are getting ignored. I did

Re: random(4) changes

On Mon, Apr 25, 2016 at 12:06 PM, Andi Kleen wrote: > Sandy Harris writes: > > There is also the third problem of horrible scalability of /dev/random > output on larger systems, for which patches are getting ignored. I did not write that. I think Andi is quoting himself here, not

random(4) changes

Stephan has recently proposed some extensive changes to this driver, and I proposed a quite different set earlier. My set can be found at: https://github.com/sandy-harris This post tries to find the bits of both proposals that seem clearly worth doing and entail neither large implementation

random(4) changes

Stephan has recently proposed some extensive changes to this driver, and I proposed a quite different set earlier. My set can be found at: https://github.com/sandy-harris This post tries to find the bits of both proposals that seem clearly worth doing and entail neither large implementation

Re: [RFC][PATCH 0/6] /dev/random - a new approach

> - Ted Jitter, havege and my maxwell(8) all claim to get entropy from variations in timing of simple calculations, and the docs for all three give arguments that there really is some entropy there. Some of those arguments are quite strong. Mine are in the P

Re: [RFC][PATCH 0/6] /dev/random - a new approach

- Ted Jitter, havege and my maxwell(8) all claim to get entropy from variations in timing of simple calculations, and the docs for all three give arguments that there really is some entropy there. Some of those arguments are quite strong. Mine are in the PDF at: https://

Re: [PATCH 1/7] A couple of generated files

This set of patches, plus some later ones that simplify the code and get rid of one major bug are now at: https://github.com/sandy-harris Directory for these changes is random.gcm An out-of-kernel test program for an older version is in random.test On Sat, Nov 7, 2015 at 1:50 PM, Sandy Harris

Re: [PATCH 1/7] A couple of generated files

This set of patches, plus some later ones that simplify the code and get rid of one major bug are now at: https://github.com/sandy-harris Directory for these changes is random.gcm An out-of-kernel test program for an older version is in random.test On Sat, Nov 7, 2015 at 1:50 PM, Sandy Harris

Re: [PATCH 1/7] A couple of generated files

tionale for this approach & the details of my implementation. random_gcm.c is not close to being a finished product, in particular my code is not yet well integrated with existing driver code. Most of the code was developed and has been fairly well tested outside the kernel. Test program is

Re: [PATCH 1/7] A couple of generated files

On Sat, Nov 7, 2015 at 12:01 PM, Jason Cooper wrote: > On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote: >> Signed-off-by: Sandy Harris >> --- >> .gitignore | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/.gitignore b/.git

[PATCH 7/7] Create generated/random_init.h, used by random driver

Signed-off-by: Sandy Harris --- Kbuild | 21 + scripts/Makefile | 1 + 2 files changed, 22 insertions(+) diff --git a/Kbuild b/Kbuild index f55cefd..494c665 100644 --- a/Kbuild +++ b/Kbuild @@ -5,6 +5,7 @@ # 2) Generate timeconst.h # 3) Generate asm-offsets.h

[PATCH 2/7] Two new CONFIG options for the random(4) driver

Signed-off-by: Sandy Harris --- drivers/char/Kconfig | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index a043107..0e0e6b5 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@ -603,5 +603,28 @@ config TILE_SROM

[PATCH 6/7] Produces generated/random_init.h for random driver

Signed-off-by: Sandy Harris --- scripts/gen_random.c | 260 +++ 1 file changed, 260 insertions(+) create mode 100644 scripts/gen_random.c diff --git a/scripts/gen_random.c b/scripts/gen_random.c new file mode 100644 index 000..07b447f

[PATCH 5/7] Conditionals for CONFIG_RANDOM_INIT and CONFIG_RANDOM_GCM

Signed-off-by: Sandy Harris --- drivers/char/Makefile | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/char/Makefile b/drivers/char/Makefile index d8a7579..7d095e5 100644 --- a/drivers/char/Makefile +++ b/drivers/char/Makefile @@ -2,7 +2,30

[PATCH 4/7] Different version of driver using hash from AES-GCM Compiled if CONFIG_RANDOM_GCM=y

Signed-off-by: Sandy Harris --- drivers/char/random_gcm.c | 3716 + 1 file changed, 3716 insertions(+) create mode 100644 drivers/char/random_gcm.c diff --git a/drivers/char/random_gcm.c b/drivers/char/random_gcm.c new file mode 100644 index 000

[PATCH 1/7] A couple of generated files

Signed-off-by: Sandy Harris --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index fd3a355..dd80bfd 100644 --- a/.gitignore +++ b/.gitignore @@ -112,3 +112,6 @@ all.config # Kdevelop4 *.kdev4 + +certs/x509_certificate_list +scripts/gen_random

[PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

Signed-off-by: Sandy Harris --- drivers/char/random.c | 50 ++ 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d0da5d8..e222e0f 100644 --- a/drivers/char/random.c +++ b/drivers/char

[PATCH 1/7] A couple of generated files

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- .gitignore | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index fd3a355..dd80bfd 100644 --- a/.gitignore +++ b/.gitignore @@ -112,3 +112,6 @@ all.config # Kdevelop4 *.kdev4 + +certs/x509_certificat

[PATCH 3/7] Initialise pools randomly if CONFIG_RANDOM_INIT=y

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- drivers/char/random.c | 50 ++ 1 file changed, 46 insertions(+), 4 deletions(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d0da5d8..e222e0f 100644 --- a/driver

[PATCH 4/7] Different version of driver using hash from AES-GCM Compiled if CONFIG_RANDOM_GCM=y

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- drivers/char/random_gcm.c | 3716 + 1 file changed, 3716 insertions(+) create mode 100644 drivers/char/random_gcm.c diff --git a/drivers/char/random_gcm.c b/drivers/char/random_gcm.c ne

[PATCH 6/7] Produces generated/random_init.h for random driver

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- scripts/gen_random.c | 260 +++ 1 file changed, 260 insertions(+) create mode 100644 scripts/gen_random.c diff --git a/scripts/gen_random.c b/scripts/gen_random.c new file mode 100644

[PATCH 5/7] Conditionals for CONFIG_RANDOM_INIT and CONFIG_RANDOM_GCM

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- drivers/char/Makefile | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/char/Makefile b/drivers/char/Makefile index d8a7579..7d095e5 100644 --- a/drivers/char/Makefile +++ b/driver

[PATCH 7/7] Create generated/random_init.h, used by random driver

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- Kbuild | 21 + scripts/Makefile | 1 + 2 files changed, 22 insertions(+) diff --git a/Kbuild b/Kbuild index f55cefd..494c665 100644 --- a/Kbuild +++ b/Kbuild @@ -5,6 +5,7 @@ # 2) Generate timeconst.

[PATCH 2/7] Two new CONFIG options for the random(4) driver

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- drivers/char/Kconfig | 23 +++ 1 file changed, 23 insertions(+) diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig index a043107..0e0e6b5 100644 --- a/drivers/char/Kconfig +++ b/drivers/char/Kconfig @@

Re: [PATCH 1/7] A couple of generated files

On Sat, Nov 7, 2015 at 12:01 PM, Jason Cooper <ja...@lakedaemon.net> wrote: > On Sat, Nov 07, 2015 at 09:30:36AM -0500, Sandy Harris wrote: >> Signed-off-by: Sandy Harris <sandyinch...@gmail.com> >> --- >> .gitignore | 3 +++ >> 1 file changed, 3 insert

Re: [PATCH 1/7] A couple of generated files

e kernel. Test program is at: https://github.com/sandy-harris/random.test I just dropped a large chunk of that code into a copy of random.c, made modifications to make the style match better & to get it to compile in the kernel context, then deleted a few chunks of existing driver code a

[PATCH] Update reference to obsolete RFC

Signed-off-by: Sandy Harris --- drivers/char/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d0da5d8..90c472b 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -231,7 +231,7 @@ * not be attributed

[PATCH] Update reference to obsolete RFC

Signed-off-by: Sandy Harris <sandyinch...@gmail.com> --- drivers/char/random.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/char/random.c b/drivers/char/random.c index d0da5d8..90c472b 100644 --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -231,7

Re: [PATCH v5 06/14] crypto: marvell/CESA: add DES support

On Tue, Jun 16, 2015 at 5:59 AM, Boris Brezillon wrote: > Add support for DES operations. Why on Earth should we do that? DES is demonstrably insecure. The only possible excuse for allowing it anywhere in a modern code base is that you need it to implement triple DES, and even that should by

Re: [PATCH v5 06/14] crypto: marvell/CESA: add DES support

On Tue, Jun 16, 2015 at 5:59 AM, Boris Brezillon boris.brezil...@free-electrons.com wrote: Add support for DES operations. Why on Earth should we do that? DES is demonstrably insecure. The only possible excuse for allowing it anywhere in a modern code base is that you need it to implement

Re: [PATCH] random: add random_initialized command line param

On Mon, May 18, 2015 at 6:58 PM, Herbert Xu wrote: > Stephan Mueller wrote: >> >> I hear more and more discussions about recommendations to use AES 256 and not >> AES 128. Or perhaps other ciphers with 256-bit keys. Salsa, ChaCha and several of the Caesar candidates support those. >> These

Re: [PATCH] random: add random_initialized command line param

On Mon, May 18, 2015 at 6:58 PM, Herbert Xu herb...@gondor.apana.org.au wrote: Stephan Mueller smuel...@chronox.de wrote: I hear more and more discussions about recommendations to use AES 256 and not AES 128. Or perhaps other ciphers with 256-bit keys. Salsa, ChaCha and several of the Caesar

Re: [PATCH v4 2/6] random: Async and sync API for accessing kernel_pool

On Sun, May 3, 2015 at 11:33 AM, Stephan Mueller wrote: > The kernel_pool is intended to be the in-kernel equivalent to the > blocking_pool, i.e. requests for random data may be blocked if > insufficient entropy is present. I cannot see any reason this would be useful, let alone necessary. Of

Re: [PATCH v4 2/6] random: Async and sync API for accessing kernel_pool

On Sun, May 3, 2015 at 11:33 AM, Stephan Mueller smuel...@chronox.de wrote: The kernel_pool is intended to be the in-kernel equivalent to the blocking_pool, i.e. requests for random data may be blocked if insufficient entropy is present. I cannot see any reason this would be useful, let alone

Read/write file from random(4) driver

I realise that in general reading files from kernel space is a bad idea, and understand at least some of the reasons. I have read Greg K-H's article on the topic (http://www.linuxjournal.com/article/8110) and some other discussion. However, I think I see a specific exception and am looking for

Read/write file from random(4) driver

I realise that in general reading files from kernel space is a bad idea, and understand at least some of the reasons. I have read Greg K-H's article on the topic (http://www.linuxjournal.com/article/8110) and some other discussion. However, I think I see a specific exception and am looking for

Re: crypto: zeroization of sensitive data in af_alg

On Sun, Nov 9, 2014 at 5:33 PM, Stephan Mueller wrote: > while working on the AF_ALG interface, I saw no active zeroizations of memory > that may hold sensitive data that is maintained outside the kernel crypto API > cipher handles. ... > I think I found the location for the first one:

Re: crypto: zeroization of sensitive data in af_alg

On Sun, Nov 9, 2014 at 5:33 PM, Stephan Mueller smuel...@chronox.de wrote: while working on the AF_ALG interface, I saw no active zeroizations of memory that may hold sensitive data that is maintained outside the kernel crypto API cipher handles. ... I think I found the location for the

RFC: Alternative to systemd?

I've been reading the debates around systemd, haven't reached any firm conclusion but the criticism that Unix programs should "do one thing and do it well" certainly resonates with me. On the other hand, this may be one of those cases where theory and practice need to differ; more-or-less all the

RFC: Alternative to systemd?

I've been reading the debates around systemd, haven't reached any firm conclusion but the criticism that Unix programs should do one thing and do it well certainly resonates with me. On the other hand, this may be one of those cases where theory and practice need to differ; more-or-less all the

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Theodore Ts'o wrote: > Fundamentally, what worries me about this scheme (actually, causes the > hair on the back of my neck to rise up on end) is this statement in > your documentation[1]: > >When looking at the sequence of time deltas gathered >during testing [D] , no pattern can be

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Theodore Ts'o ty...@mit.edu wrote: Fundamentally, what worries me about this scheme (actually, causes the hair on the back of my neck to rise up on end) is this statement in your documentation[1]: When looking at the sequence of time deltas gathered during testing [D] , no pattern can

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Stephan Mueller wrote: > [quoting me] >> ...your code is basically, with 64-bit x: >> >> for( i=0, x = 0 ; i < 64; i++, x =rotl(x) ) >>x |= bit() > > Why not declare some 64-bit constant C with a significant >>number of bits set and do this: >> >> for( i=0, x = 0 ; i < 64; i++, x

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller wrote: >>Why not declare some 64-bit constant C with a significant > > Which constant would you take? The CRC twist values? The SHA-1 initial > values? Or the first few from SHA-256? The only essential requirement is that it not be something

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller wrote: > Another thing: when you start adding whitening functions, other people > are starting (and did -- thus I added section 4.3 to my documentation) > to complain that you hide your weaknesses behind the whiteners. I simply > want to counter

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris wrote: > Stephan Mueller wrote: >> Can you please help me understand why you think that a whitening >> function (cryptographic or not) is needed in the case of the CPU Jitter >> RNG, provided that I can show that each indiv

Fwd: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Stephan Mueller wrote: >>Paper has: >> >>" the time delta is partitioned into chunks of 1 bit starting at the >>lowest bit " The 64 1 bit chunks of the time value are XORed with >>each other to " form a 1 bit value. >> >>As I read that, you are just taking the parity. Why not use that

Fwd: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Stephan Mueller smuel...@chronox.de wrote: Paper has: the time delta is partitioned into chunks of 1 bit starting at the lowest bit The 64 1 bit chunks of the time value are XORed with each other to form a 1 bit value. As I read that, you are just taking the parity. Why not use that

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 9:38 AM, Sandy Harris sandyinch...@gmail.com wrote: Stephan Mueller smuel...@chronox.de wrote: Can you please help me understand why you think that a whitening function (cryptographic or not) is needed in the case of the CPU Jitter RNG, provided that I can show

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 10:40 AM, Stephan Mueller smuel...@chronox.de wrote: Another thing: when you start adding whitening functions, other people are starting (and did -- thus I added section 4.3 to my documentation) to complain that you hide your weaknesses behind the whiteners. I simply

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Mon, Oct 14, 2013 at 11:26 AM, Stephan Mueller smuel...@chronox.de wrote: Why not declare some 64-bit constant C with a significant Which constant would you take? The CRC twist values? The SHA-1 initial values? Or the first few from SHA-256? The only essential requirement is that it not be

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

Stephan Mueller smuel...@chronox.de wrote: [quoting me] ...your code is basically, with 64-bit x: for( i=0, x = 0 ; i 64; i++, x =rotl(x) ) x |= bit() Why not declare some 64-bit constant C with a significant number of bits set and do this: for( i=0, x = 0 ; i 64; i++, x

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller wrote: I like the basic idea. Here I'm alternately reading the email and the page you link to & commenting on both. A nitpick in the paper is that you cite RFC 1750. That was superceded some years back by RFC 4086

Re: [PATCH] CPU Jitter RNG: inclusion into kernel crypto API and /dev/random

On Fri, Oct 11, 2013 at 2:38 PM, Stephan Mueller smuel...@chronox.de wrote: I like the basic idea. Here I'm alternately reading the email and the page you link to commenting on both. A nitpick in the paper is that you cite RFC 1750. That was superceded some years back by RFC 4086

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

Stephan Mueller wrote: > Ted is right that the non-deterministic behavior is caused by the OS > due to its complexity. ... >> > For VM's, it means we should definitely use >> > paravirtualization to get randomness from the host OS. >> ... > > That is already in place at least with KVM and Xen

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

Stephan Mueller smuel...@chronox.de wrote: Ted is right that the non-deterministic behavior is caused by the OS due to its complexity. ... For VM's, it means we should definitely use paravirtualization to get randomness from the host OS. ... That is already in place at least with KVM

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o wrote: > I continue to be suspicious about claims that userspace timing > measurements are measuring anything other than OS behaviour. Yes, but they do seem to contain some entropy. See links in the original post of this thread, the havege stuff

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

I very much like the basic notion here. The existing random(4) driver may not get enough entropy in a VM or on a device like a Linux router and I think work such as yours or HAVEGE (http://www.irisa.fr/caps/projects/hipsor/) are important research. The paper by McGuire et al of "Analysis of

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

I very much like the basic notion here. The existing random(4) driver may not get enough entropy in a VM or on a device like a Linux router and I think work such as yours or HAVEGE (http://www.irisa.fr/caps/projects/hipsor/) are important research. The paper by McGuire et al of Analysis of

Re: [PATCH][RFC] CPU Jitter random number generator (resent)

On Tue, May 21, 2013 at 3:01 PM, Theodore Ts'o ty...@mit.edu wrote: I continue to be suspicious about claims that userspace timing measurements are measuring anything other than OS behaviour. Yes, but they do seem to contain some entropy. See links in the original post of this thread, the

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Thu, Feb 21, 2013 at 9:17 AM, Stephan Mueller wrote: > There is no state between calls. Of course, you need a scratchpad to do > calculations. But in general you need a buffer. It is quite easy to construct scenarios where several K bits of entropy are needed very -- for example, reboot an

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Thu, Feb 21, 2013 at 9:17 AM, Stephan Mueller smuel...@chronox.de wrote: There is no state between calls. Of course, you need a scratchpad to do calculations. But in general you need a buffer. It is quite easy to construct scenarios where several K bits of entropy are needed very -- for

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sun, Feb 10, 2013 at 2:32 PM, Stephan Mueller wrote: > On 10.02.2013 19:50:02, +0100, Theodore Ts'o wrote: > Given all your doubts on the high-precision timer, how can you > reasonably state that the Linux kernel RNG is good then? > > The data from add_timer_randomness the kernel feeds into

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sun, Feb 10, 2013 at 1:50 PM, Theodore Ts'o wrote: > On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote: >> >> However, the CPU has timing jitter in the execution of instruction. And >> I try to harvest that jitter. The good thing is that this jitter is >> always present and can

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sun, Feb 10, 2013 at 1:50 PM, Theodore Ts'o ty...@mit.edu wrote: On Sun, Feb 10, 2013 at 01:46:18PM +0100, Stephan Mueller wrote: However, the CPU has timing jitter in the execution of instruction. And I try to harvest that jitter. The good thing is that this jitter is always present and

Re: [RFC][PATCH] Entropy generator with 100 kB/s throughput

On Sun, Feb 10, 2013 at 2:32 PM, Stephan Mueller smuel...@chronox.de wrote: On 10.02.2013 19:50:02, +0100, Theodore Ts'o ty...@mit.edu wrote: Given all your doubts on the high-precision timer, how can you reasonably state that the Linux kernel RNG is good then? The data from

[speculation] Partitioning the kernel

I'm wondering whether we have or need a formalisation of how work might be divided in future kernels. The question I'm interested in is how the work gets split up among various components at different levels within a single box (not SMP with many at the same level, or various multi-box

[speculation] Partitioning the kernel

I'm wondering whether we have or need a formalisation of how work might be divided in future kernels. The question I'm interested in is how the work gets split up among various components at different levels within a single box (not SMP with many at the same level, or various multi-box

Re: [PATCH] Prevent OOM from killing init

Kurt Garloff wrote: > Kernel related questions IMHO are: > (1) Why do we get into OOM? There was a long thread about this a few months back. We get into OOM because malloc(), calloc() etc. can allocate more memory than is actually available. e.g. Say you have machine with 64 RAM + 64 swap =

Re: [PATCH] Prevent OOM from killing init

Kurt Garloff wrote: Kernel related questions IMHO are: (1) Why do we get into OOM? There was a long thread about this a few months back. We get into OOM because malloc(), calloc() etc. can allocate more memory than is actually available. e.g. Say you have machine with 64 RAM + 64 swap = 128

  1   2   >