Re: [PATCH] drivers/net: remove network drivers' last few uses of IRQF_SAMPLE_RANDOM

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Jesper Juhl
Date: Thursday, May 15, 2008 - 3:57 pm

2008/5/16 Theodore Tso <tytso@mit.edu>:

Hmm, I would like to know how you'd do that.
Even if you a) know the exact distro installed (and the configuration,
b) know the exact hardware in the machine, c) know the exact time it
was booted and know that there have been no ssh logins or similar that
might have generated syscalls, d) know exactely how many requests (and
of what type) have been made to the server and the exact times they
were made.
How would you go about brute force guessing the contents of the entropy pool?

If the server does, for example, this; every second it samples the
number of syscalls made during that second and uses that number as the
base of adding one or two bits of entropy. Every time a syscall is
made it uses the "time since last syscall in 'us'" to add one bit of
entropy to the pool. I'd say that even if that server sees very little
(and even predictable) traffic, we may have; details of the filesystem
layout on disk, a timer interrupt happening a few microseconds early
due to a flaky chip, a background process initiating some action a
millisecond early/late for scheduling reasons, the switch the machine
is connected to causing a network packet to arrive a tiny bit later
than normal and various other factors like that, to cause the
generated entropy to be off by a bit or two compared to your guess -
and by the time you realize you are off, another spurrious event has
probably happened, so you'll never end up in-sync with the entropy
pool...  Or is there some "obvious entropy pool guessing method" that
I'm just not aware of???


Yes, I'm aware of that, and I'm not suggesting to use syscall rates as
a generator of high amounts of high quality entropy. Im merely
suggesting that sampling syscall rates and time-between and using
those numbers as the source of very low amounts of low quality entropy
might be worth-while. It wouldn't hurt on machines that have other,
higher quality, entropy sources. On machines that have no other
entropy sources it would ensure that we always have a steady (although
slow) trickle of new entropy info available...

I'm only talking about providing some data for /dev/random here.

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
RE: [PATCH] drivers/net: remove network drivers' last few ..., Brandeburg, Jesse, (Thu May 15, 9:07 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Henrique de Moraes H ..., (Thu May 15, 3:29 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Jesper Juhl, (Thu May 15, 3:57 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Henrique de Moraes H ..., (Thu May 15, 4:02 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Henrique de Moraes H ..., (Thu May 15, 4:46 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Henrique de Moraes H ..., (Thu May 15, 4:58 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 6:21 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 7:15 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 10:36 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 11:41 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 11:42 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Lennart Sorensen, (Fri May 16, 1:39 pm)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Alejandro Riveira , (Mon May 26, 6:43 am)
Re: [PATCH] drivers/net: remove network drivers' last few ..., Krzysztof Halasa, (Mon May 26, 2:07 pm)