In message <20180407160031.gb12...@roeckx.be> on Sat, 7 Apr 2018 18:00:32 +0200, Kurt Roeckx <k...@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 levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project