In message <[email protected]> on Sat, 7 Apr 2018 17:46:50 +0200, Kurt Roeckx <[email protected]> said:
kurt> On Sat, Apr 07, 2018 at 02:15:51PM +0000, Salz, Rich wrote: kurt> > I would like to see this put on hold until we fix the ‘now requires 50% more random seeding’ issue. kurt> > kurt> > What should I do to force that issue? kurt> kurt> NIST SP800-90A rev1 section 8.6.7 has: kurt> | A nonce may be required in the construction of a seed during kurt> | instantiation in order to provide a security cushion to block kurt> | certain attacks. The nonce shall be either: kurt> | kurt> | a. A value with at least (security_strength/2) bits of entropy, or kurt> | b. A value that is expected to repeat no more often than a kurt> | (security_strength/2)-bit random string would be expected to repeat. kurt> | kurt> | Each nonce shall be unique to the cryptographic module in which kurt> | instantiation is performed, but need not be secret. When used, the kurt> | nonce shall be considered to be a critical security parameter. kurt> | kurt> | A nonce may be composed of one (or more) of the following kurt> | components (other components may also be appropriate): kurt> | 1. A random value that is generated anew for each nonce, using an kurt> | approved random bit generator. kurt> | 2. A timestamp of sufficient resolution (detail) so that it is kurt> | different each time it is used. kurt> | 3. A monotonically increasing sequence number, or kurt> | 4. A combination of a timestamp and a monotonically increasing kurt> | sequence number, such that the sequence number is reset when and kurt> | only when the timestamp changes. For example, a timestamp may show kurt> | the date but not the time of day, so a sequence number is appended kurt> | that will not repeat during a particular day. kurt> | kurt> | For case 1 above, the random value could be acquired from the same kurt> | source and at the same time as the entropy input. In this case, kurt> | the seed could be considered to be constructed from an kurt> | “extra strong” entropy input and the optional personalization kurt> | string, where the entropy for the entropy input is equal to or kurt> | greater than (3/2 security_strength) bits. kurt> | kurt> | For case 2 above, the timestamp must be trusted. A trusted kurt> | timestamp is generated and signed by an entity that is trusted kurt> | to provide accurate time information. kurt> kurt> Case 1 requires an approved random bit generator, which we don't kurt> have by default. kurt> kurt> Case 2 requires the timestamp to be trusted. I think that applies kurt> to case 4 too. This is also something we can't do by default. I'm not sure what you mean with "trusted"... kurt> I think case 3 requires us keep a counter even after restarting kurt> the application, which seems unlikely that we will implement it. kurt> kurt> So by default we can't do any of them. But you can argue that we kurt> can do case 1, 2 and 4 close enough. Case 1 is what we do now. Hmmmm... case 4 shouldn't pose too much problems unless you restart the application more than once every second or so (for a 1 second resolution). On VMS, the system time is kept with 100 nanosecond granularity... this doesn't mean that it's actually updated every 100 nanosecond, but the possibility is there when VMS runs on fast enough hardware (a VAX is decidedly not in that range, Alpha has a minimum update rate of 1ms, Itaniums are faster than most Alphas...). Either way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit counter to match the 128 bit nonce requirement, do I get that right? kurt> I think we can do case 2 with something like gettimeofday() or kurt> clock_gettime() which I think provide plenty of resolution kurt> that it's unlikely to repeat. kurt> kurt> You can combine that with a counter to get case 4 if you really kurt> wanted. kurt> kurt> All you have to do is implement a get_nonce() function and set kurt> it by default. You can keep the behaviour that if no get_nonce kurt> function is set that it increases the entropy requirement. Aha ok! Yeahok, I see, so if I implement a rand_drbg_get_nonce in rand_vms.c, we're basically set... but that means we need to implement a generic one as well, no? -- Richard Levitte [email protected] OpenSSL Project http://www.openssl.org/~levitte/ _______________________________________________ openssl-project mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-project
