[openssl-project] Entropy seeding the DRBG

Richard Levitte levitte at openssl.org
Sat Apr 7 17:00:21 UTC 2018


In message <20180407160031.GB12191 at roeckx.be> on Sat, 7 Apr 2018 18:00:32 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sat, Apr 07, 2018 at 04:58:06PM +0200, Richard Levitte wrote:
kurt> > > Can I suggest you try something like
kurt> > > https://github.com/usnistgov/SP800-90B_EntropyAssessment to at least
kurt> > > get an idea? You would need to sample 1 variable and feed that into
kurt> > > it.
kurt> > 
kurt> > And yeah, sure, especially if all it takes is to produce a stream of
kurt> > bits from a source and feed that to the assessment program.  As long
kurt> > as I don't have to port a C++11 program to VMS, 'cause unfortunately,
kurt> > the existing C++ compiler hasn't had a real update for quite a while
kurt> > :-/ (I'm sure that VSI is quite busy updating all they can, but they
kurt> > haven't let anything out yet)
kurt> 
kurt> You only need to generate the bits on VMS, you can run the tool on
kurt> some other machine.

Cool.

kurt> If you have such a program that collects the bits, I would like
kurt> to review it. I would also like to test something like that over
kurt> a range of machines it's expected to run on.

Errrrrrr....  I have no idea what you're talking about.  I know of no
other operating system that provides the system services VMS does, so
I wonder how you expect to run the program gathering those data on
anything other than VMS.

If you wanna know what I'm talking about, just have a look at this
page:

http://h41379.www4.hpe.com/doc/84final/4527/4527pro_contents.html

Every "command" that starts with a '$' is a system service.  The C API
has them prefixed with 'sys$'.  The one of hightes interest seems to
be $GETRMI (or sys$getrmi), which has all sorts of counters and other
data.

kurt> I wonder if it's useful to have a thread of VMS that collects
kurt> such bits all the time, like the kernel is doing.

I was pondering something like that, and it does make sense.  That, or
creating a generic device driver (RND0:) that works a bit like the
random driver on Linux, or perhaps the one from OpenBSD...

kurt> I'm going to guess that the 4 bit you count now is an overestimate.

Don't look at me, it was I who made that estimate...  but I agree with
your guess.

kurt> And I would like to be very conservative in estimating something
kurt> like that, and even divide what the tool returns by 10.

That's a reason I want to go for a computed estimate instead...  the
3rd order delta that Linux' random driver does with jiffies seemed
like a simple enough strategy.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/


More information about the openssl-project mailing list