> -----Original Message-----
> From: Salz, Rich [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 10, 2000 9:55 AM

> >Can somebody tell me if this method of seeding the RNG secure enough?
> 
> It's not.  Not by a LONG shot.

If we want to be pedantic, "secure enough" is only meaningful in terms of a
threat model.  If my model is "I'm only doing preliminary development, I
don't care if anyone cracks my SSL sessions, and I'm explicitly eliminating
the danger of forgetting to fix the code before it's released from my threat
pool", then that method is certainly "secure enough", since the model
doesn't require any security at all.

For any real application, it's hard to imagine a threat model that justifies
going through the effort of using SSL but permits crippling SSL to almost no
strength.

> On Win32, there's a function to load the PRNG from the screenbuffer.

Which is only useful if your threat model assumes it'll be hard for an
attacker to get the contents of the screenbuffer, of course.

If I were developing for Win32, I'd be strongly tempted to use Counterpane's
Yarrow PRNG, the Win32 implementation of which comes with an entropy
collector (or so I understand - I haven't actually gotten around to looking
at it yet).

Yarrow is free and probably strong, which is more than you can say for most
PRNGs.  See http://www.counterpane.com/yarrow.html.

EGD looks like the popular entropy source for Unix variants that lack a good
/dev/random at the moment.

> >additional seed in the form of PID, thread ID, system time, and
> >other private data.
> 
> Of the items you listed, all of them could be easily guessed. :)

That's frighteningly close to the original - broken - Netscape
implementation, in fact.  (As I'm sure Rich, and many others on the
openssl-users list, know already.)

There's an RFC - I'm feeling too lazy to look up which at the moment - that
discusses cryptographic random number generation, bias-removal correctors,
and similar issues.  It points out how vulnerable even likely-looking
sources like network time skew can be to a dedicated attacker in the right
place.

With crypto PRNGs, you have two choices: use a complete implementation (from
seeding on up) designed for the purpose from a source you trust, or study
the subject in some depth before putting any trust in it whatsoever.

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]

Reply via email to