Mike,
>> Again, /dev/urandom is just as "secure" as /dev/random. Its the same
>> pool. The same stuff. Except that /dev/random blocks when the entropy
>> count hits 0.
>
> You have been repeating that there is no difference in security
> between /dev/random and /dev/urandom, but consider this: you install
> a kernel/hardware combination without any registered SA_SAMPLE_RANDOM
> IRQs (i.e. headless, no IDE, no NICs with SA_SAMPLE_RANDOM IRQs).
(& no access to any block devices - but leave that for the time
being)
> The entropy pool for such a system starts at 0s, unless I'm
> misreading the source; from create_entropy_store():
>
> memset(r->pool, 0, poolwords*4);
>
> As long as no interrupt ever adds randomness to this pool, I might be
> able to predict every bit ever read from /dev/random on this machine.
You would read precisely 0 bits from /dev/random, as it would
sit there blocking, with no entropy in the system.
You would be able to predict the bits from /dev/urandom.
Both pretty useless for generating useful random numbers,
but the blocking behaviour is probably safer.
This is the 'seeding' problem we refer to. After you've seeded
the random number generator (perhaps provide some entropy from
a file from the last boot), you wouldn't have this problem. And
/dev/urandom and /dev/random stay the same.
The suggestion of counting various events which are 'reasonably
unpredictable' but potentially observable, but not count them
as entropy, helps the seeding problem. Noone has argued that
using network IRQs to add randomness to the pool, but NOT count
as entropy, would be bad.
> /dev/random is very good for making sure you never generate a GPG
> key on a machine like this. I agree with most people on this thread
> that session keys are usually safe coming from /dev/urandom. But you
> should still make sure you have at least one device feeding into
> the entropy pool, something I'm sure many admins have no clue about
> and don't verify.
If they have none, they will know it very soon, as /dev/random will
block. It is currently hard to boot without accessing block devices,
however (and yes, on a duplicated machine, with embedded hardware
with predictable timing and no moving parts, this isn't much of
an entropy source either).
-- Alex Bligh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 23 2001 - 21:00:47 EST