On Sun, Apr 08, 2018 at 10:31:58AM +0200, Richard Levitte wrote: > In message <20180408080942.gb3...@roeckx.be> on Sun, 8 Apr 2018 10:09:42 > +0200, Kurt Roeckx <k...@roeckx.be> said: > > kurt> On Sun, Apr 08, 2018 at 07:39:30AM +0200, Richard Levitte wrote: > kurt> > In message <20180407190250.ga27...@roeckx.be> on Sat, 7 Apr 2018 > 21:02:51 +0200, Kurt Roeckx <k...@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.
Yes, after what I all said previously, it's clear the code could use improvements. I think at least Matthias and I assumed the code about the minimum size was correct and that there was a minimum requirement of 128 bit. Kurt _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project