But you CAN'T pass it known text. Even when you write to /dev/random
the information you write is stirred in to the pool, it doesn't replace
the current contents of the pool. And it isn't counted in the entropy
count. The entropy count is very conservative...
>Think about it. We cannot generate infinit amount of random output, based
>on a finit amount of random input. Ie. the output wont be random. The more
>output you give, the more information you expose, isnt it so?
Even MD5 so far has only fallen to some pretty contrived chosen-plaintext
attacks. SHA hasn't fallen even to those, as far as I'm aware. But a
chosen-plaintext attack won't work on the random device, because you
can't choose the plaintext.
But your point is exactly why there are separate /dev/random and
/dev/urandom; in theory, if SHA or MD5 (either can be used as the
stirring function; see random.c) is broken from the standpoint
of analyzing only the hashes they generate, you can still trust
output from /dev/urandom. The possibility of that happening any
time soon is not large, so /dev/random is indistinguishable in
practice form /dev/urandom.
I suggest reading all the comments in random.c and reading chapters
16, 17, and 18 (and any previous chapters you need to understand those
chapters) of Applied Cryptography by Schneier before continuing this
discussion. I'm not a cryptographer, but I have some faith, at least,
in Ted's cryptographic ability, and so I trust his cryptographic
code more than an uninformed critique. If you want to make an informed
critique of his code, you *need* to have some decent understanding
of cryptography. Thus my reading recommendation...
michaelkjohnson
"Magazines all too frequently lead to books and should be regarded by the
prudent as the heavy petting of literature." -- Fran Lebowitz