> From: Lutz Jaenicke [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 20, 2000 1:09 PM
>
> On Tue, Jun 20, 2000 at 01:51:34PM -0400, Bill Rebey wrote:
> > [what's the PRNG seed data used for, and why is it important?]
> The question is not the amount of data, it is the amount of
> "unpredictability".
More precisely, it's the difficulty of reproducing the PRNG stream, which
boils down to the difficulty of reproducing the PRNG seed. You could seed
your PRNG with a "completely unpredictable" (I know, that's unprovable, but
that's another argument) 1-bit seed; I can't guess what bit value you used,
but I can brute force it pretty easily.
> From the PRNG the random numbers used to encrypt the session are generated
> (and even the secrect keys).
In short, the PRNG seed is a total-exposure vulnerability. If the seed
isn't hard to guess, you're wide open.
The original SSL 1.0 crack against Netscape exploited precisely this
problem. Netscape was seeding its PRNG with easily-guessed data: the time,
process ID, and parent process ID. (The last was particularly stupid on the
server, since server instances were generally running under init, making
PPID a constant 1.)
> Most (all?) UNIX machines
> use increasing process numbers, so these numbers are not so difficult to
> "guess".
Easily-guessable PIDs are a covert channel, and Unix implementations that
try to avoid covert channels don't use simple-increment PID generators. AIX
v3 and above, for example, combines a "process slot number" with a per-slot
counter. Unfortunately, this scheme is still guessable in relatively rare
situations (an otherwise idle machine running a single process over and over
again will tend to loop through the counter on the same slot), and it tends
to repeat PIDs more frequently than simple one-up schemes do.
But the answer's still the same: using the PID is a bad idea, too.
> The actual time is easily guessed, as is the computer time used
> up by your process (times()), since I might have the same computer and
> simply try :-)
Attacks against generators seeded with the time (eg. the Netscape crack)
typically try to probe the target's time-of-day clock using the daytime
service and its ilk. But that's just to simplify the brute-forcing a bit;
as Bernard pointed out in another note, if we can get even the day when the
PRNG was seeded, we have half the time data (assuming seconds granularity).
A millisecond clock is a bit better, but still not great.
For that matter, RAND_screen isn't great either, particularly on a server
that does its work in the background. It's probably good enough for most
casual security threat models, but I wouldn't use it for anything that had
to be protected against a determined attacker.
There's a ton of literature on seeding PRNGs. In fact, there's an RFC,
though I've forgotten which one it is. It has a nice discussion of the
seeding problem, issues with the obvious techniques (eg. network timings),
compression functions used to reduce bias in seed material, etc. Should be
easy to find from one of the online RFC sources.
Michael Wojcik [EMAIL PROTECTED]
MERANT
Department of English, Miami University
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
