It is 64 - 160 BITS
Which is 8 - 20 OCTETS
or 4 - 10 BYTES
And
openssl rand -hex n
Generates n BYTES
Thus what openssl does by default for a self-signed cert, e.g. a root CA
cert of a serial of 8 BYTES is indeed Best Practice, given that if the
first bit were ONE, the serial would then be 8 BYTES.
I had to slow down, take a step away, to see that I was tripping my self
up on the OCTET/BYTE bit.
So I am correcting my guide to use
openssl rand -hex 8
And the probability of a collision is just not worth talking about.
in a population of 2^64, 1 million random selections has a 2.7E-6 %
collision probability.
You go up to 1 billion and the probability does drop to 2.7%.
In a population of 2^159, you have to select 10^18 to get a collision
probability of 6.8E11 %; just not worth dealing with.
So randomly selecting serial numbers will unlikely result in collisions
if you are doing this for you IoT run of 10 million per year, using an 8
BYTE serial number.
And since we are using SHA256 with ECDSA, the known attacks are just not
real. Yet.
So in my highly biased opinion....
If you have the memory and bandwidth, go ahead with 8 bytes for serial.
In constrained IoT, 4 bytes works.
Also going to next look at BER over DER for IoT usage.
BTW the above calculations are based on:
p = 1 - e^{-k^2/(2n)}
Where n = total population and k is selected subset.
Bob
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
