Clearing up some of my mistakes on serial number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux