lkml.org 
[lkml]   [2008]   [May]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-05-16 18:23    [W:0.191 / U:0.524 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site