[openssl-project] FW: [openssl/openssl] VMS: lower the entropy demand for this platform specifically (#5904)

[Richard Levitte]

In message <20180407154649.GA12191 at roeckx.be> on Sat, 7 Apr 2018 17:46:50 +0200, Kurt Roeckx <kurt at roeckx.be> 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         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/