[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <482DB43D.2090504@firstfloor.org>
Date: Fri, 16 May 2008 18:20:13 +0200
From: Andi Kleen <andi@...stfloor.org>
To: Adrian Bunk <bunk@...nel.org>
CC: Alan Cox <alan@...rguk.ukuu.org.uk>, Jeff Garzik <jeff@...zik.org>,
netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
"Brandeburg, Jesse" <jesse.brandeburg@...el.com>,
Chris Peterson <cpeterso@...terso.com>,
tpmdd-devel@...ts.sourceforge.net, tpm@...horst.net,
Herbert Xu <herbert@...dor.apana.org.au>
Subject: Re: [PATCH] Re: [PATCH] drivers/net: remove network drivers' last
few uses of IRQF_SAMPLE_RANDOM
Adrian Bunk wrote:
> On Fri, May 16, 2008 at 12:19:49PM +0200, Andi Kleen wrote:
>> ...
>> The only problem you got from possible bogus input is that the entropy
>> counts will be wrong, but in my experience nearly all programs
>> use /dev/urandom anyways because /dev/random is just a DoS waiting
>> to happen and user space programmers know that.
>> ...
>
> If programs just need some random data without relying on the fact that
> it's cryptographically strong /dev/urandom is the right choice.
No in this case /dev/urandom is the wrong choice. You should seed
then some standard RND with the time,pid as is the classical way
and not use any precious entropy. Yes some programs don't do that,
but they're wrong and actually slightly dangerous.
> But some programs need entropy for doing crypto stuff, and a local DoS
> is harmless compared to the consequences of bad /dev/random data.
Even the cryptographic programs normally use /dev/urandom to get
session keys etc. That is because they are definitely concerned about
local DoS. Just strace your ssh daemon or your SSL web server to see
what I mean.
> Consider as a worst case the just discovered OpenSSL bug in Debian where
> all accounts with public key authentification and keys created on a
> Debian/Ubuntu system during the last 20 months [1] can be taken over by
> an attacker within less than 20 minutes with a simple brute force
> attack. [2]
Yes, but if you read the context of that patch it commented out
the code that accessed /dev/urandom!
Please reread my analysis of the issue. If you have already entropy in
the pool the additional feed doesn't change anything. And if you don't
it still stays the same.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists