Clearing up some of my mistakes on serial number

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Clearing up some of my mistakes on serial number

Robert Moskowitz
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
Reply | Threaded
Open this post in threaded view
|

Re: Clearing up some of my mistakes on serial number

Viktor Dukhovni

> On Aug 20, 2017, at 8:35 AM, Robert Moskowitz <[hidden email]> wrote:
>
> It is 64 - 160 BITS

Correct, with the word "cryptographically random" somewhere in
there, for at least 64 of the bits.

> Which is 8 - 20 OCTETS

Correct, since an "octet" is 8 bits.

> or 4 - 10 BYTES

No, a "byte" nowdays is the same as an "octet", though there have been
variant definitions of byte, while "octets" have always been 8 bits.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Clearing up some of my mistakes on serial number

OpenSSL - User mailing list
In reply to this post by Robert Moskowitz
If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded.

OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits.
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Clearing up some of my mistakes on serial number

Robert Moskowitz
In reply to this post by Viktor Dukhovni


On 08/20/2017 09:32 AM, Viktor Dukhovni wrote:

>> On Aug 20, 2017, at 8:35 AM, Robert Moskowitz <[hidden email]> wrote:
>>
>> It is 64 - 160 BITS
> Correct, with the word "cryptographically random" somewhere in
> there, for at least 64 of the bits.
>
>> Which is 8 - 20 OCTETS
> Correct, since an "octet" is 8 bits.
>
>> or 4 - 10 BYTES
> No, a "byte" nowdays is the same as an "octet", though there have been
> variant definitions of byte, while "octets" have always been 8 bits.
>
ARGH!!!

I am going back to bed....  :)

:)

Thanks Viktor.

But my bit collision analysis still holds true.  Collisions are not a
concern if openssl rand is a good prf.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Clearing up some of my mistakes on serial number

Robert Moskowitz
In reply to this post by OpenSSL - User mailing list


On 08/20/2017 09:50 AM, Salz, Rich via openssl-users wrote:
> If you generate 19 bytes or RAND output, it will never exceed 20 bytes encoded.
>
> OpenSSL will be generating 159 bits of RAND output, so that it will never exceed 20 bytes encoded. The command-line RAND program is bytes, the C API is bits.
>  
>
So Viktor reminded me about bits, bytes and octets.

Too much on the brain.  No real excuse.

Back to the drawing broad.

A bit.

8 bits is a byte.  8 bits is a byte.  8 bits is a byte.  8 bits is a byte.

Two hex positions is a byte.  One hex position is a nibble.

:)

I'll get it straight yet.

Bob

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users