On 05/19/2011 06:20 PM, Tim Watts wrote:
On 19/05/11 16:46, Peter Sylvester wrote:
The problem with this scheme is that it doesn't deal well with
parallel certificate signatures. You have one shared information that
must be incremented in an atomic way. But for a "Junk CA" (that's how
I call the set of scripts I use), that's not a problem.
another approach is to take the value of 'time' (the current second)
and append to it the current process number, and, in case of
several machines, some number indicating the id of the machine.
instead of the process number, any other method to ensure uniqueness
within a second may be used.
Ah yes - that would guarantee a non repeating unpredictable sequence.
well, I was reminded that the number of forks may be predictable, but
one can add some random or do some random process generation, so that
you would have a large unpredictable part.
I was confuse initially as I did not realise the serial number could be so big
(16 bytes was it?).
160 bits, let's say 159 you would take 39 for the date, and add a few bits of
local
uniqueness eg, a microsecond which is already difficult to predict,
and then you still have about 100 possible random bits.
Cheers
Tim
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
