On 9/10/2012 12:42 PM, Dag-Erling Smørgrav wrote:
> Doug Barton <do...@freebsd.org> writes:
>> If the problem with replay attacks is as bad as Arthur suggest it is,
>> it should be visible in far less than a million tries.
>
> I was exaggerating a bit - but my reasoning was that since it hasn't
> blown up in our faces yet, it's probably subtle enough to require a
> large number of samples.
... or doesn't exist at all. :)
And even if it did exist, but requires thousands of reboots to see a
duplicate, then for all intents and purposes it still doesn't exist for
any reasonable use case given that after the system has been up for more
than 5-10 minutes with a typical load there will have been way more than
sufficient hardware entropy harvested to make the internal state
"unique" for all practical purposes.
If I were Arthur, here is how I would test the "replay attack" assertion:
1. Install a virgin system with everything as it was before David's
first commit, and let it run for 24 hours with all the defaults intact.
Ideally, have it do something over the network periodically to make sure
that some kind of entropy is harvested from the network drivers. Run
'find / -name SASLKASDJKL' to make sure you get some from the disk
drivers too.
2. Disable the cron job for the /var/db/entropy script, and comment out
the writing of /entropy at shutdown time in /etc/rc.d/random.
3. Write a script to reboot, and once the system is fully booted do 'dd
if=/dev/random of=saved-random-out.$i count=4096' then reboot again
immediately. Values of i from 1 to 10,000 ought to do it.
4. sha256 the saved-random-out files and see how many duplicates there are.
This is simple to automate, and won't cost anything but a little time to
set it up.
Doug
--
I am only one, but I am one. I cannot do everything, but I can do
something. And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
