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.
...
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
