On Dec 11, 2011, at 2:52 PM, Mouse wrote:
I'm not entirely sure what I mean by that. It's difficult to explain,
even to myself.
I think anyone who hack on NetBSD understands why you must, Mouse. We may not
understand why you must do *this* particular thing, but we at least understand
the
[I tried to send this as private mail, but get
host Sparkle-4.Rodents-Montreal.ORG[216.46.5.7] refused to talk to me:
550-.de's whois server, whois.denic.de, is completely broken, [...]
I wrote up a point-by-point reply to this, but then realized, this is
tech-kern, not
On Sun, Dec 11, 2011 at 12:35:07PM +0100, Edgar Fu? wrote:
[I tried to send this as private mail, but get
host Sparkle-4.Rodents-Montreal.ORG[216.46.5.7] refused to talk to me:
550-.de's whois server, whois.denic.de, is completely broken, handing
550-out no contact information at all
[...]
The short answer is that Mouse likes tilting at windmills. :-)
Eh. I think that is at least a little of a misstatement. I don't do
such things because I enjoy doing them. Quite the opposite.
I do them because I must.
I'm not entirely sure what I mean by that. It's difficult to
On Sun, Dec 11, 2011 at 02:52:28PM -0500, Mouse wrote:
[...]
The short answer is that Mouse likes tilting at windmills. :-)
Eh. I think that is at least a little of a misstatement. I don't do
such things because I enjoy doing them. Quite the opposite.
I do them because I must.
On Fri, Dec 09, 2011 at 02:41:25PM -0500, Paul Koning wrote:
... That's essentially what old time Ethernet chips like Lance did
IIRC The lance's CSMACD backoff was deterministic, if you were
really unlucky two systems could collide packets for ever!
(On a network with only 2 hosts.)
On a
On Dec 11, 2011, at 5:18 PM, David Laight wrote:
On Fri, Dec 09, 2011 at 02:41:25PM -0500, Paul Koning wrote:
... That's essentially what old time Ethernet chips like Lance did
IIRC The lance's CSMACD backoff was deterministic, if you were
really unlucky two systems could collide packets
On 9 Dec, 2011, at 17:38 , Mouse wrote:
A PRNG cannot create information; its output contains no more
information than its input. If it is keyed with 128 bits, say, it
cannot produce more than 2^128 different output keystreams, even if
those keystreams are far longer, and thus appear to
On Fri, Dec 09, 2011 at 08:41:25AM +0200, Alan Barrett wrote:
I have this naive idea that trying to get out more than you put in
is cheating, and I think it's fine for /dev/urandom to cheat, but I
am not happy about /dev/random cheating. Please could you explain
where I have misunderstood.
On Fri, Dec 09, 2011 at 09:45:40AM -0500, Thor Lancelot Simon wrote:
Suffice to say I think the state of affairs is a lot better now than
it was before. And note that at least one highly-thought-of modern
design for an entropy collector (Fortuna) doesn't even _try_ to
keep an entropy estimate
In what sense are bits really ever taken out?
Revealed to userland, of course.
The idea here is that entropy that has been revealed to userland might
as well not be present. With good mixing at appropriate points, this
is of questionable truth, but it is, as you said, a very conservative
On Fri, Dec 09, 2011 at 10:35:32AM -0500, Mouse wrote:
In what sense are bits really ever taken out?
Revealed to userland, of course.
The idea here is that entropy that has been revealed to userland might
as well not be present. With good mixing at appropriate points, this
is of
On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
An attacker who can break AES might be able to predict
the future output of _one_ instance of the generator. An
attacker who can break AES and recover the key and defeat the
backtracking resistance designed into CTR_DRBG *might* be able
to
On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
Fair enough, but you still seem to be talking about how good a
CSPRNG it is, whereas my concern is that it's pseudorandom, nor
random.
So was the output from the old entropy pool. Again, look at the
implementation!
As soon as
On Fri, Dec 09, 2011 at 12:14:40PM -0500, Thor Lancelot Simon wrote:
Let me put it this way: before, you may have thought you were getting
some kind of true randomness. You weren't. Now, you still aren't,
but at least what sits between you and the entropy source is a lot
more clear, and a
On Fri, Dec 09, 2011 at 06:52:16PM +0200, Alan Barrett wrote:
On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
An attacker who can break AES might be able to predict
the future output of _one_ instance of the generator. An
attacker who can break AES and recover the key and defeat the
[I'm pulling together multiple mails from tls here. The second-level
quotes are from varying people; I've marked their authors according to
the info I have.]
[Mouse]
Revealed to userland, of course.
Combined with the conservative approach to estimating how much
entropy was put into the pool,
You are aware of the fact that 99.99% of computers don't have true
random number generators and the bits you claim that are random are
not random at all?
Actually, practically all computers have true random number generators.
The first problem is that neither they nor their interfaces are
-Original Message-
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Mouse
Sent: Friday, December 09, 2011 2:34 PM
To: tech-secur...@netbsd.org; tech-kern@NetBSD.org; tech-cry...@netbsd.org
Subject: Re: Patch: new random pseudodevice
You
On Fri, 09 Dec 2011, Thor Lancelot Simon wrote:
On Fri, Dec 09, 2011 at 12:14:40PM -0500, Thor Lancelot Simon
wrote:
Let me put it this way: before, you may have thought you were
getting some kind of true randomness. You weren't. Now,
you still aren't, but at least what sits between you and
On Fri, Dec 09, 2011 at 02:23:34PM -0500, Mouse wrote:
You appear to think that anything that's not pure true randomness must
be pure PRNG. The old randomness pool was neither; it was a hybrid.
I think we have a basic disagreement here. I don't grant that there
is such a thing as hybrid
-Original Message-
From: tech-kern-ow...@netbsd.org [mailto:tech-kern-ow...@netbsd.org] On
Behalf Of Mouse
Sent: Friday, December 09, 2011 2:24 PM
To: tech-secur...@netbsd.org; tech-kern@NetBSD.org; tech-cry...@netbsd.org
Subject: Re: Patch: new random pseudodevice
...
I think
On Fri, 09 Dec 2011, Pawel Jakub Dawidek wrote:
You are aware of the fact that 99.99% of computers don't have
true random number generators and the bits you claim that are
random are not random at all? They try to be unpredictable.
I believe that there is a truly random component to air
(do we need so many lists?)
I've read Thor's answer to Alan, that started:
You didn't misunderstand. The people who designed the entropy pool
misunderstood. In what sense are bits really ever taken out? But,
back then, the whole idea was so new that being very conservative
and I +1 the
http://mail-index.netbsd.org/tech-security/1999/08/08/.html
On Dec 9, 2011, at 3:15 52PM, Thor Lancelot Simon wrote:
(1) Strong bits suitable for direct use as things like crypto keys.
Using a PRNG here, even a really good one, is a major fail.
This may be your opinion, but it differs radically from the opinion of
almost every expert in the field
[Another omnibus reply.]
Thor has several different arguments, but some of them seem to amount
to the old way was broken, therefore the new way is better. I
certainly hope I'm misreading those, because the Thor I thought I knew
is smart to seriously support that kind of stance.
The old way was
On Dec 9, 2011, at 2:38 PM, Steven Bellovin wrote:
Imagine
what would happen if someone upgraded the disk to a flash disk or
one with a large flash cache
Heh, I was gonna say -- I haven't carried around a computer that actually has
a hard drive in it for at least a year now.
-- thorpej
I have placed a patch at http://www.panix.com/~tls/rndpseudo.diff
which removes direct userspace access to the kernel entropy pool. It
is replaced with the NIST SP 800-90 CTR_DRBG generator, separately
keyed per pseudodevice open (actually, keyed on first read or select so
opens don't themselves
On Thu, 08 Dec 2011, Thor Lancelot Simon wrote:
The urandom device node will key the generator and output data
even if the kernel entropy pool estimates that it does not
have enough bits to provide an AES-128 key with ful entropy.
The random device node will block until sufficient bits are
30 matches
Mail list logo
