[openssl-project] Entropy seeding the DRBG
paul.dale at oracle.com
Wed Apr 25 21:20:46 UTC 2018
A stream of bytes. They don't need to contain eight bit data.
NIST's SP 800-90B wants 1,000,000 bytes to do the estimation (there are restart tests as well worry about them after good sources are determined). The source shouldn't be manipulated with anything other than xor -- a wide source can be thinned by xoring the bytes together but not by shifting and xoring e.g.
I suspect you'll be sampling the sources periodically -- this is OS and workload dependent. Even for a continuously changing good source, you'll want to sample slower to avoid impacting the CPU too much.
Dr Paul Dale | Cryptographer | Network Security & Encryption
Phone +61 7 3031 7217
From: Kurt Roeckx [mailto:kurt at roeckx.be]
Sent: Wednesday, 25 April 2018 3:25 AM
To: openssl-project at openssl.org
Subject: Re: [openssl-project] Entropy seeding the DRBG
On Tue, Apr 24, 2018 at 07:20:42AM +0200, Richard Levitte wrote:
> Like I think I mentioned a few days ago, I'm currently on a conference. I'll take this up in more depth later this week.
> I have a question, though... Kurt said at some point that all that was needed on the VMS side was to collect data, the rest can be done elsewhere (thankfully). However, I don't really understand what the collected data is supposed to be. Just the same stream of bytes that I would feed the entropy acquisition, or something else? Is the time delta between samples a factor in this?
The API support getting data that has 1 bit of entropy per 128 bit received (DRBG_MINMAX_FACTOR). If it's worse than that, you might have to write your own extract method.
A stream of bytes it just fine.
I think the tme delta will really depend on your source. If it really changes all the time, it really doesn't matter much how fast you do it. But I think some (most?) of the variables don't change that often.
openssl-project mailing list
openssl-project at openssl.org
More information about the openssl-project