On Wed, 18 Dec 2002 11:58:52 +0100, Gaël Le Mignot said:
> This is the current implementation, yes, but /dev/urandom doesn't guarantee
> anything about the "quality" of the random bits. It can be secure, but it
It does. It even blocks (well, I checked years ago) as long as the
entropy pools has
On Tue, 17 Dec 2002 13:36:21 +0100, Gaël Le Mignot said:
> And /dev/urandom is not really done for "cryptographic secure" randomness,
> it's the goal of /dev/random, not /dev/urandom (and AFAIK ssh only uses
That is not really true. The common implementations of /dev/[u]random
for *BSD and Linux
ts in a more appropriate
way.
Ciao,
Werner
--
Werner KochOmnis enim res, quae dando non deficit, dum habetur
g10 Code GmbH et non datur, nondum habetur, quomodo habenda est.
Privacy Solutions-- Augustinus
entations apply a hash at least to the output (see rfc1750
for the reasons, why this is a Good Thing). So you can't do any
statistical tests on the output.
The only way to analyze a CSPRNG is by a careful aanlyze of the code.
Werner
--
Werner KochOmnis enim res, quae dando non defici
"Thomas Bushnell, BSG" <[EMAIL PROTECTED]> writes:
> I've thought a little about this. I think the best sources of random
> bits come from disk latencies and keystroke patterns and network
Especially keystrokes. Ted Tso's driver is GPLed and not very system
dependend. (/usr/src/linux/drivers/c
5 matches
Mail list logo