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

[Kurt Roeckx]

On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
> In message <20180407154649.GA12191 at roeckx.be> on Sat, 7 Apr 2018 17:46:50 +0200, Kurt Roeckx <kurt at roeckx.be> said:
> 
> 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"...

It's right there in the quoted text, it needs to be signed.

But I wonder how that it supposed to really work. If you want to
avoid a replay attack, does that mean you need to use a nonce? Do
we bootstrap problem?

> 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?

What is not clear to me is that all DRBGs (the 1+2N) need to have
a unique nonce or not. The 3 first are all most likely to be
instantiated very close to each other. It might be that the
requirement is the nonce for all 3 is different. If you combine
this with a counter (case 4), it's easy to do this on a per
process basis, even if the time is only updated once per second.

But maybe the requirement can be over multiple processes? I really
don't know enough about this.

> 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?

It might be a little strange that the default is different on
different platforms, but I don't see why that should be a problem.
But having a generic one is probably more useful to a VMS specific
one.


Kurt