[openssl-project] Entropy seeding the DRBG
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> > 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> You only need to generate the bits on VMS, you can run the tool on
kurt> some other machine.
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
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
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
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.
Richard Levitte levitte at openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
More information about the openssl-project