Re: [RFC] frandom - fast random generator module

[Kent Borg]

On Thu, Oct 23, 2003 at 11:22:53AM +0800, Sandy Harris wrote:
> That's not secure; four bytes give only 2^32 = 4 billion odd
> possibilities. An enemy can easily enumerate them all as the
> start of an attack.

It depends upon whether the foe can get access to the encrypted/hashed
copy, and it depends upon the importance of the password.  For
example, what properties do you think my amazon.com password should
have?  Is a sufficiently motivated foe really likely to get access?
And what is the cost of that happening?  I think 32-bits of entropy is
quite reasonable for such uses.  Certainly for some uses, such as
encrypted communications, 32-bits is not enough, but have you tried
remembering a passphrase with, say, 128-bits of entropy?  It can be
done, but it is not easy.  And entering such a passphrase blind (with
no echo) is not easy either.  

I want normal people with normal notivations to be able to keep their
computers secure, and expecting a normal person to use such a long
passphrase not reasonable.  Let's keep the shadow file not world
readable, and then 32-bit passwords are secure.

> > -kb, the Kent who would like to see the kernel's random number
> > generator improved
> 
> I think we'd all like to see it improved if possible. The question
> is how, and why?

Actually, I think much of what I was thinking of has been done for
2.6.

> > ability to supply some initial entropy early in the
> > boot--for embedded devices
> 
> [...]
> 
> Do you think you need this before there's a file system? Why?
> Or are you thinking of boxes that don't have a file system?
> Or not writable? Not local?

I am thinking of little embedded boxes which can cobble up some
trickle of entropy once running (frequently from the network), and
probably find a place to store some, but at the very beginning of
their first boot, before opening networking or before it has been up
for long, at the point when they might want to generate ssh keys, it
would be nice to have ~some~ entropy.  One source would be to hash the
power-on contents of some of the DRAM.  Yes, I know DRAM does not come
up in a random state, but it does not come up in a predictable state
either; there *is* some entropy there.  Make a digest of a megabyte.
How many bits need vary from one boot to another (or even easier, from
one physical chip to another) to produce a useful lump of entropy?
Yes, I know that a warm boot might have no entropy in RAM contents,
but in the case of a warm boot there can be some saved entropy, and
mixing in known data does the entropy pool no harm.  And hashing a
megabyte of RAM is not that expensive, even on a slow CPU.

Maybe I am wrong about needing entropy so early, but if it is
collected before Linux boots, it needs to be stored somewhere, and it
would be nice to be able to free that space when Linux frees other
boot memory.


-kb
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/