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

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 02:15:51PM +0000, Salz, Rich wrote:
> I would like to see this put on hold until we fix the ‘now requires 50% more random seeding’ issue.
> 
> What should I do to force that issue?

NIST SP800-90A rev1 section 8.6.7 has:
| A nonce may be required in the construction of a seed during
| instantiation in order to provide a security cushion to block
| certain attacks. The nonce shall be either:
|
| a. A value with at least (security_strength/2) bits of entropy, or
| b. A value that is expected to repeat no more often than a
| (security_strength/2)-bit random string would be expected to repeat.
|
| Each nonce shall be unique to the cryptographic module in which
| instantiation is performed, but need not be secret. When used, the
| nonce shall be considered to be a critical security parameter.
|
| A nonce may be composed of one (or more) of the following
| components (other components may also be appropriate):
| 1. A random value that is generated anew for each nonce, using an
| approved random bit generator.
| 2. A timestamp of sufficient resolution (detail) so that it is
| different each time it is used.
| 3. A monotonically increasing sequence number, or
| 4. A combination of a timestamp and a monotonically increasing
| sequence number, such that the sequence number is reset when and
| only when the timestamp changes. For example, a timestamp may show
| the date but not the time of day, so a sequence number is appended
| that will not repeat during a particular day.
|
| For case 1 above, the random value could be acquired from the same
| source and at the same time as the entropy input. In this case,
| the seed could be considered to be constructed from an
| “extra strong” entropy input and the optional personalization
| string, where the entropy for the entropy input is equal to or
| greater than (3/2 security_strength) bits.
|
| For case 2 above, the timestamp must be trusted. A trusted
| timestamp is generated and signed by an entity that is trusted
| to provide accurate time information.

Case 1 requires an approved random bit generator, which we don't
have by default.

Case 2 requires the timestamp to be trusted. I think that applies
to case 4 too. This is also something we can't do by default.

I think case 3 requires us keep a counter even after restarting
the application, which seems unlikely that we will implement it.

So by default we can't do any of them. But you can argue that we
can do case 1, 2 and 4 close enough. Case 1 is what we do now.

I think we can do case 2 with something like gettimeofday() or
clock_gettime() which I think provide plenty of resolution
that it's unlikely to repeat.

You can combine that with a counter to get case 4 if you really
wanted.

All you have to do is implement a get_nonce() function and set it
by default. You can keep the behaviour that if no get_nonce function
is set that it increases the entropy requirement.


Kurt

that