Re: lynx-dev SSL for Lynx 2.8.4

[David Woolley]

> random state file if one is available, the time, and the PID,) then pull a
                                             ^^^^

The time, except for the milliseconds and microseconds parts, is useless
for creating cryptographic random numbers.

> random state file if one is available, the time, and the PID,) then pull a
                                                           ^^^
This helps a bit, assuming an attacker has no other access to it (all
local attackers do), and even then, it means that successive numbers
are not completely independent and that and that the machine has been
running many days (otherwise there is a bias to low numbers).

> long's worth of random bytes out of the PRNG and use it to seed the
> system-supplied random number generator, and then pull random numbers off of
> the system's RNG until the PRNG is happy.  I then write out some randomness

This is fixing a symptom, not creating true entropy.  The output of the
system's RNG is a deterministic function (maybe with some difficult to
recover information about the number of cycles) of the seed.  Worse,
one doesn't know the precise function on each platform.

> to disk for next time.  It could be made better, but this is more than
> sufficient for what we're trying to accomplish after a few runs to get the
> stored randomness well churned.

You are churning it, making it more difficult to invert the state, but
you are not adding entropy, so a brute force forwards approach may be
feasible (the strongest link is the cumulative stored randomness).

I repeat that most failures in big name commercial crypto systems
recently have been due to thnks like predictable random numbers and
other operational laxness (it was procedural laxness that really made
Enigma breakable in WW II, as well).

; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden