Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers

[Sami Farin <7atbggg02@sneakemail.com>]

On Sat, May 06, 2006 at 21:22:00 -0400, Theodore Tso wrote:
... 
> I could ask questions about why the insecure Windows box is on the
> same network as the box processing the credit card transactions, or
> how the attacker is familiar with the network topology, or knows the
> clock frequencies of your CPU(s) and when your box was last rebooted
> so it can make guesses about the TSC values that will be hashed in ---

Currently init_std_data plays only with do_gettimeofday and
system_utsname.  Why not also feed get_cycles(), jiffies, pointer
to init_std_data function or something to add_entropy_words?

For example, I notice that syncookie_secret is initialized very early
in the boot, and it's never written to again.
If system clock is +-1 s accurate at boot and kernel is from
some common distro, I wonder how secure syncookie_secret is.

And if I read correctly, get_random_int() keeps producing the
same output during the same jiffy, if CONFIG_X86_HAS_TSC is undef?
Why not create a new function for get_random_int()
(instead of just calling secure_ip_id())
which includes 64bit-counter, pid and jiffies in the hash given
to half_md4_transform?

Also, I believe add_input_randomness needs fixing.
I noticed that when using e.g. evdev in Xorg, one mouse movement or
button press causes eight events, and all of them are fed to
add_timer_randomness.  There maybe 7 out of 8 of the events
get 1 bit of entropy added because they happen on the same jiffy.

I have been playing with Fortuna patch (JLC's patch with 
dozens of fixes by me), and from looking at debug outputs,
it seems that last input "event" is marked by
  (type == 0) && (code == 0) && (value == 0) ...

So I am doing this way:
keep on jhash'ing type, code, value in add_input_randomness
till they're all-zeros,
then give the resulting u32 to add_timer_randomness.
jhash value can be static variable and you can ignore the
fact you are "mixing" different events from different
sources into the hash.

Now when I press and release ANY key (or e.g. click mouse button),
I get exactly two calls to add_timer_randomness, which each add
3-11 bits of entropy.  I think this is how it should work.
At least 3 bits doesn't sound too overestimated ;-O

And for disk events, maybe limit to at max a couple of
calls to add_timer_randomness per jiffy?
Maybe also limit similarly in add_input_randomness?
(For disk events I also add disk_stat_read(disk, sectors[0]/[1])
 as entropy)

For add_interrupt_randomness, if there anything what could
be added as entropy, besides irq and time?

http://safari.iki.fi/fortuna-random-2.6.16.14-safari.patch.bz2
Warning: enabling debug might produce sensitive data into log files
and/or console.
/proc/sys/kernel/random/debug specifies which debugs to produce
(valid values 0-63 , OR 1, 2, 4, 8, 16, 32 together).
If link does not seem to work, I am either rebooting a
a newer Fortuna version or my system blew up or I have
dropped your packets with netfilter.

What about adding entropy from data received from network?
For example, with netfilter module, pass every Nth checksum
from a packet (for example, from DNS replies) to
add_entropy_words() ?

> or know which CPU (for SMP boxes) an interrupt will be processed on
> since on current Intel/AMD boxes the TSC is not synchronized.  But
> even if the attacker knows all of this, the attacker still doesn't
> know the current starting point of the pool.   
...

--