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

[Richard Levitte]

In message <20180408080942.GB3653 at roeckx.be> on Sun, 8 Apr 2018 10:09:42 +0200, Kurt Roeckx <kurt at roeckx.be> said:

kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote:
kurt> > In message <20180407190250.GA27401 at roeckx.be> on Sat, 7 Apr 2018 21:02:51 +0200, Kurt Roeckx <kurt at roeckx.be> said:
kurt> > 
kurt> > kurt> On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote:
kurt> > kurt> > Hmmmm...  case 4 shouldn't pose too much problems unless you restart
kurt> > kurt> > the application more than once every second or so (for a 1 second
kurt> > kurt> > resolution).  On VMS, the system time is kept with 100 nanosecond
kurt> > kurt> > granularity...  this doesn't mean that it's actually updated every 100
kurt> > kurt> > nanosecond, but the possibility is there when VMS runs on fast enough
kurt> > kurt> > hardware (a VAX is decidedly not in that range, Alpha has a minimum
kurt> > kurt> > update rate of 1ms, Itaniums are faster than most Alphas...).  Either
kurt> > kurt> > way, the timestamp is 64 bits, it seems that then, we'd add a 64-bit
kurt> > kurt> > counter to match the 128 bit nonce requirement, do I get that right?
kurt> > kurt> 
kurt> > kurt> The requirement is not to have it 128 bit. Just that it doesn't
kurt> > kurt> repeat as often as a 128 random number. You're most likely not
kurt> > kurt> going to instantiate it 2^64 times. As long as the combination is
kurt> > kurt> unique, it should be fine.
kurt> > 
kurt> > "The requirements" depend on where you look.  Looking at the code, or
kurt> > more specifically drbg_ctr_init in drbg_ctr.c, about line 421, I see
kurt> > this:
kurt> > 
kurt> >         drbg->min_noncelen = drbg->min_entropylen / 2;
kurt> > 
kurt> > So the DRBG CTR code currently requires 128 bits minimum by default,
kurt> > unconditionally.
kurt> 
kurt> The standard does not require this 128 bit. This 128 bit is only
kurt> required for the random value. The example even has a nonce of 32
kurt> bit.

So then maybe the code in drbg_ctr_init() shouldn't set such a high
minimum when drbg->get_nonce is defined?  That, or RAND_DRBG_instantiate()
shouldn't try to check against drbg->min_noncelen, i.e. the latter
should only be used when drbg->get_nonce is undefined.

I don't know enough to decide what's appropriate here...

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/