> AB> 2. Given that otherwise in at least my application (and machine
> AB> without keyboard and mouse can't be too uncommon) there is *no*
> AB> entropy otherwise, which is rather easier for a hacker. At least
> Put a soundcard in your system and install audio-entropyd.
> Works pretty nice.
I> Do
On Mon, Apr 09, 2001 at 01:04:47PM +0200, Heusden, Folkert van wrote:
> >> However, only 3 drivers in drivers/net actually set
> >> SA_SAMPLE_RANDOM when calling request_irq(). I believe
> >> all of them should.
> > No, because an attacker can potentially control input and make it
> > non-random.
>> However, only 3 drivers in drivers/net actually set
>> SA_SAMPLE_RANDOM when calling request_irq(). I believe
>> all of them should.
> No, because an attacker can potentially control input and make it
> non-random.
AB> 2. Given that otherwise in at least my application (and machine
AB> without
Jeff et al.,
>> However, only 3 drivers in drivers/net actually set
>> SA_SAMPLE_RANDOM when calling request_irq(). I believe
>> all of them should.
>
> No, because an attacker can potentially control input and make it
> non-random.
Point taken but:
1. In that case, if we follow your logic, no d
Alex Bligh - linux-kernel wrote:
>In debugging why my (unloaded) IMAP server takes many seconds
>to open folders, I discovered what looks like a problem
>in 2.4's feeding of entropy into /dev/random. When there
>is insufficient entropy in the random number generator,
>reading from /dev/random blo
On Sun, Apr 08, 2001 at 11:46:21PM +0100, Alex Bligh - linux-kernel wrote:
> The following patch fixes eepro100.c - others can be
> patched similarly.
Problem is that it allows someone with sniffer access to your network to
make a pretty good estimate of your random pool. If you search the archiv
Alex Bligh - linux-kernel wrote:
> The machine in question is locked in a data center (can't be
> the only one) and thus sees none of the former two. IDE Entropy
> comes from executed IDE commands. The disk is physically largely
> inactive due to caching. But there's plenty of network traffic
> wh
In debugging why my (unloaded) IMAP server takes many seconds
to open folders, I discovered what looks like a problem
in 2.4's feeding of entropy into /dev/random. When there
is insufficient entropy in the random number generator,
reading from /dev/random blocks for several seconds. /dev/random
is
8 matches
Mail list logo
