On Sun, May 07, 2006 at 11:00:14AM -0500, Matt Mackall wrote:
> Yes, CRC-16 was a rhetorical device. MD4 would not have been.
MD4 is succeptible to a 2nd pre-image attack, yes. This means that
given a specific message and its MD4 checksum, you can find another
message which will have the same MD4 checksum. But that doesn't help
you at all if you only have the MD4 checksum. And even the 2nd
pre-image attack still requires O(2**40) operations. That's within
the reach of modern CPU's yes, but that simply gives you a *second*
pre-image that has the same MD4 checksum as original message.
In order to crack the entropy pool, you need a large number of outputs
from /dev/random, and be able to find a large number of pre-images
very rapidly. This is the main reason why I believe the entropy
accounting is still useful. Even if the entropy accounting is off by
several orders of magnitude, it is still useful, since the attacks
that we're talking about will very likely require a huge number of
data points. For example, the most powerful cryptoanalytic attack
against DES still requires 2**43 plaintext/ciphertext pairs.
But in answer to your question, what should we do, my suggestion would
be to sample all interrupts, and calculate the estimated entropy
credits as we to day, but scaled by an amount that can range from 0 to
100%. This amount can be configured by system administrators, and
will have intelligent defaults for each device driver to the amount of
entropy should be credited for a particular device. If we care, we
can set the default percentage scalaing factor for platforms with no
TSC reguster and HZ=100 to be zero. But for most normal/modern
platforms, I would argue the default scaling factor should be 100%.
The bottom line is this is much ado about nothing. As I have said,
most programs use /dev/urandom, not /dev/random; the only really
appropriate use of /dev/random is to generate long-term public/private
keypairs, or perhaps to seed some other cryptographic random number
generator (like /dev/urandom).
- Ted
-
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]
