On Sat, Apr 07, 2018 at 06:49:50PM +0200, Richard Levitte wrote: > In message <20180407154649.ga12...@roeckx.be> on Sat, 7 Apr 2018 17:46:50 > +0200, Kurt Roeckx <k...@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 _______________________________________________ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project