From: antirez <antirez@invece.org>
To: Alex Bligh - linux-kernel <linux-kernel@alex.org.uk>
Cc: Andreas Dilger <adilger@turbolabs.com>,
Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>,
linux-kernel@vger.kernel.org, "Theodore Ts'o" <tytso@mit.edu>
Subject: Re: /dev/random entropy calculations broken?
Date: Tue, 2 Oct 2001 00:43:16 +0200 [thread overview]
Message-ID: <20011002004316.D2155@blu> (raw)
In-Reply-To: <20011001105927.A22795@turbolinux.com> <45266246.1001976925@[195.224.237.69]>
In-Reply-To: <45266246.1001976925@[195.224.237.69]>; from linux-kernel@alex.org.uk on Mon, Oct 01, 2001 at 10:55:26PM +0100
On Mon, Oct 01, 2001 at 10:55:26PM +0100, Alex Bligh - linux-kernel wrote:
> However, unless one is worried about someone having broken
> SHA-1 OR one is worried about annoying blocking behavour
> on read(), I'm not convinced the entropy calculation is
> doing anything useful anyway.
I think the /dev/random /dev/urandom solution is perfect
from this point of view. Using /dev/random you can get
random number that are secure _even_ if tomorrow SHA1 will
be broken at the cost of a very slow generation.
Or you may trust SHA1 (or some other crypto primitive) to
avoid to collect too much entropy to generate the output.
Probably real world applications should use
/dev/urandom, assuming it's properly designed, i.e. the
internal state is changed once there is enough entropy
to create a new unguessable key, the entropy isn't
overstimated, and so on.
BTW I agree, instead to create a key being paranoid about
the SHA1 security it's better to double check if the
entropy source is ok. For example the linux PRNG used
to collect a lot of entropy bits from the keyboard
auto-repeat aaaaaaaaaaaaaa ...
It's useless to try to collect enough entropy (and maybe
overstimating it) to produce an output secure against
SHA1 possible weakness (i.e. totally generated with
entropy bits). It's probably better a more conservative
approach in the entropy collection and to use a belived secure
crypto primitive to produce the PRNG output.
After all, unless you are using a one-time pad probably
the key generated with /dev/random will be used with
the crypto algorithms you refused to trust.
--
Salvatore Sanfilippo <antirez@invece.org>
http://www.kyuzz.org/antirez
finger antirez@tella.alicom.com for PGP key
28 52 F5 4A 49 65 34 29 - 1D 1B F6 DA 24 C7 12 BF
next prev parent reply other threads:[~2001-10-01 22:51 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-25 23:36 [PATCH][RFC] Allow net devices to contribute to /dev/random Robert Love
2001-09-26 0:20 ` David Wagner
2001-09-26 0:52 ` Robert Love
2001-09-26 1:36 ` David Wagner
2001-09-26 22:55 ` Gordon Oliver
2001-09-26 23:06 ` Andreas Steinmetz
2001-09-26 15:49 ` dean gaudet
2001-09-26 17:00 ` Oliver Xymoron
2001-10-01 14:43 ` Pavel Machek
2001-10-01 21:33 ` Robert Love
2001-10-01 9:52 ` Florian Weimer
2001-10-01 16:59 ` /dev/random entropy calculations broken? Andreas Dilger
2001-10-01 21:55 ` Alex Bligh - linux-kernel
2001-10-01 22:43 ` antirez [this message]
2001-10-02 7:51 ` Andreas Dilger
2001-10-02 8:10 ` Andreas Dilger
2001-10-02 15:37 ` Oliver Xymoron
2001-10-02 21:02 ` Andreas Dilger
2001-10-02 21:29 ` Oliver Xymoron
2001-10-02 22:28 ` Andreas Dilger
2001-10-19 22:59 ` [PATCH] " Andreas Dilger
2001-10-21 5:05 ` Robert Love
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=20011002004316.D2155@blu \
--to=antirez@invece.org \
--cc=Florian.Weimer@RUS.Uni-Stuttgart.DE \
--cc=adilger@turbolabs.com \
--cc=linux-kernel@alex.org.uk \
--cc=linux-kernel@vger.kernel.org \
--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