public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Stephan Mueller <smueller@chronox.de>
Cc: herbert@gondor.apana.org.au, Theodore Tso <tytso@mit.edu>,
	Andi Kleen <andi@firstfloor.org>,
	sandyinchina@gmail.com,
	Jason Cooper <cryptography@lakedaemon.net>,
	John Denker <jsd@av8n.com>,
	"H. Peter Anvin" <hpa@linux.intel.com>,
	Joe Perches <joe@perches.com>, George Spelvin <linux@horizon.com>,
	linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 0/7] /dev/random - a new approach
Date: Mon, 20 Jun 2016 10:27:40 +0200	[thread overview]
Message-ID: <20160620082740.GA10238@amd> (raw)
In-Reply-To: <3817952.8FvMDE0Kc7@tauon.atsec.com>

Hi!

> > 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 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 as well as in virtual
> > > environments and when using SSDs. A secondary design goal is to limit the
> > > impact of the entropy collection on massive parallel systems and also
> > > allow the use accelerated cryptographic primitives. Also, all steps of
> > > the entropic data processing are testable. Finally massive performance
> > > improvements are visible at /dev/urandom and get_random_bytes.
> > 
> > Dunno. It is very similar to existing rng, AFAICT. And at the very
> > least, constants in existing RNG could be tuned to provide "entropy at
> > the boot time".
> 
> The key differences and thus my main concerns I have with the current design 
> are the following items. If we would change them, it is an intrusive change. 
> As of now, I have not seen that intrusive changes were accepted. This led me 
> to develop a competing algorithm.

Well, intrusive changes are hard to do, but replacing whole subsystems
is even harder -- and rightly so.

> - There was a debate around my approach assuming one bit of entropy per 
> received IRQ. I am really wondering about that discussion when there is a much 
> bigger "forcast" problem with the legacy /dev/random: how can we credit HIDs 
> up to 11 bits of entropy when the user (a potential adversary) triggers these 
> events? I am sure I would be shot down with such an approach if I would 
> deliver that with a new implementation.

Well, if you can demonstrate 11 bits is too much, go ahead... I'm sure
that is rather easy to adjust.

But I believe that 1) user is not normally an adversary and 2) the
best thing for him to do would still be "pressing nothing". It will be
hard to press keys (etc) with great enough precision...

Best regards,
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2016-06-20  8:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-19 15:58 [PATCH v5 0/7] /dev/random - a new approach Stephan Mueller
2016-06-19 15:59 ` [PATCH v5 1/7] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller
2016-06-19 15:59 ` [PATCH v5 2/7] random: conditionally compile code depending on LRNG Stephan Mueller
2016-06-19 16:00 ` [PATCH v5 3/7] crypto: Linux Random Number Generator Stephan Mueller
2016-06-19 16:58   ` Andi Kleen
2016-06-19 18:31     ` Stephan Mueller
2016-06-19 16:00 ` [PATCH v5 4/7] crypto: LRNG - enable compile Stephan Mueller
2016-06-19 16:01 ` Stephan Mueller
2016-06-19 16:01 ` [PATCH v5 6/7] crypto: isolate the chacha20_block function Stephan Mueller
2016-06-19 16:04 ` [PATCH v5 7/7] crypto: LRNG - add ChaCha20 support Stephan Mueller
2016-06-19 19:36 ` [PATCH v5 0/7] /dev/random - a new approach Pavel Machek
2016-06-19 20:47   ` Sandy Harris
2016-06-20  5:51   ` Stephan Mueller
2016-06-20  8:27     ` Pavel Machek [this message]
2016-06-20 15:28     ` Theodore Ts'o
2016-06-20 15:43       ` Stephan Mueller
2016-06-20 18:44         ` George Spelvin
2016-06-20 19:00           ` Stephan Mueller
2016-06-21  5:12             ` Theodore Ts'o
2016-06-21  5:17               ` Stephan Mueller
2016-06-21  7:12         ` Nikos Mavrogiannopoulos
2016-06-21  7:32           ` Stephan Mueller
2016-06-21 16:03             ` Austin S. Hemmelgarn
2016-06-21 16:28               ` Stephan Mueller
2016-06-21 18:22                 ` Austin S. Hemmelgarn
2016-06-21 18:46                   ` Stephan Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160620082740.GA10238@amd \
    --to=pavel@ucw.cz \
    --cc=andi@firstfloor.org \
    --cc=cryptography@lakedaemon.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@linux.intel.com \
    --cc=joe@perches.com \
    --cc=jsd@av8n.com \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=sandyinchina@gmail.com \
    --cc=smueller@chronox.de \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox