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