PEM_write_bio_RSAPrivateKey assure Randomness of PK

PEM_write_bio_RSAPrivateKey assure Randomness of PK

My question is:
I have this handy function to create a Private and Public key
But what is the magic I put around it to make sure it is random not the same
Private and Public key when I run this program each time?

I am using openSSL on OSX and Android. I am not familiar with the random API
seeding
though I can pick the UUID of the device or whatever.

* I am sure there is some standard call unless of course the Initialization
of openSSL does the random seed nicely?*

Re: PEM_write_bio_RSAPrivateKey assure Randomness of PK

> On May 23, 2018, at 1:08 PM, redpath <[hidden email]> wrote:
>
> SO if I add this RAND usage below, em I seeding to assure a different RSA key
> pair each time run of
> creating a RSA pair.
>
> I would certainly replace the time with the UUID of the device to be unique
> to the device.
> You would have to acquire the device to know the seeding. Hey keep the Time
> one too.

NO. Seeding exclusively in this way is a terrible idea and MUST NOT be
done. You need considerably more randomness than found in a timestamp
or a device serial number.

It is not enough for keys to be unique, they need to be computationally
unpredictable.

If the device is generating keys it needs a decent source of randomness.
Otherwise, keys might need to be generated elsewhere and loaded onto the
device.

Re: PEM_write_bio_RSAPrivateKey assure Randomness of PK

Not trying to be insulting, but if you think time is a good source, then you really don't know what you're doing for RNG's. Consider looking at the master branch, with its highly-improve seeding and RNG code.

You'll get a *different* key pair (with high probability) each time, provided you wait at least a second between generating keys. That is, if you get anything at all; you may not, if there isn't enough entropy in the pool.

You'll also get completely pointless keys, because the wall-clock time contains little entropy.

As Viktor wrote: DO NOT DO THIS. If you don't understand why, stop trying to use cryptography until you've learned enough about the subject to be a bit less dangerous.

> I would certainly replace the time with the UUID of the device to be unique
> to the device. You would have to acquire the device to know the seeding.

Or get the UUID through any other means, such as a malicious app.

And generating two key pairs after seeding with UUID || time means the CPRNG state differs only by the 32 bits in time - and most of those will be the same, unless a *long* time has passed. So the joint information of the pairs is high, which is a Bad Thing.

And UUIDs are only 128 bits, so the total seed size is 160 bits; and neither the UUID nor the time are completely random (far from it), so you only have a small amount of entropy. DO NOT DO THIS.

There's no point in using a real cipher if you're going to starve your CPRNG. Just use a toy cipher - it's less work for you, and you won't be making false promises of security.

If you want to do this right:

1) Learn something about cryptography.
2) Gather sufficient entropy from suitable sources. If nothing else, have the user scribble on the touchscreen and track pointer movement. It's still easy to overestimate the entropy of that sort of thing, but it's better than nothing, and indeed better than what many people do for seeding.

Oh, and asking questions about OpenSSL, a smart move is to mention what version of OpenSSL you're using, platform details, and something about the problem you're trying to solve.

Re: PEM_write_bio_RSAPrivateKey assure Randomness of PK

On 23.05.2018 20:39, Michael Wojcik wrote:

>> From: openssl-users [mailto:[hidden email]] On Behalf
>> Of redpath
>> Sent: Wednesday, May 23, 2018 13:08
>> To: [hidden email]>> Subject: Re: [openssl-users] PEM_write_bio_RSAPrivateKey assure
>> Randomness of PK
>>
>> SO if I add this RAND usage below, em I seeding to assure a different RSA key
>> pair each time run of creating a RSA pair.
>
> You'll get a *different* key pair (with high probability) each time, provided you wait at least a second between generating keys. That is, if you get anything at all; you may not, if there isn't enough entropy in the pool.
>
> You'll also get completely pointless keys, because the wall-clock time contains little entropy.
>
> As Viktor wrote: DO NOT DO THIS. If you don't understand why, stop trying to use cryptography until you've learned enough about the subject to be a bit less dangerous.
>

... if this is code going in the general direction of "production
deployment", then get a crypto-person on board, or at least get them to
review and sign off the code. Otherwise this *will* end in a debacle.

Re: PEM_write_bio_RSAPrivateKey assure Randomness of PK

Well what I was alluding to is this the correct use of the RAND_add function
to seed the Key generation. Its a bit confusing certainly. I will use more
than the UUID
of the device but you have to have the device in hand to know that and know
it came from
a device.

I certainly will use better than time and UUID, just need to know calling
this seed of the rand function
is the right thing to do to effect the Key generation?

Then second all I need to do is solve the random seeding to be less than a
toy input for entropy, this is just an example that I must use RAND_add

So my correct usage of RAND_add validate? and second I will find a good
input for it.
Just let me know, thanks for taking the quick time to address this.

1.0.2 is currently a Long-Term Support (LTS) release, but support ends at the end of 2019. 1.1.1 is the new LTS release, and since 1.1 introduced a number of API changes and new features, I think it's worthwhile moving to 1.1.1 (at the latest fix level) as soon as is convenient.

That said, 1.0.2o is fine as well - just keep in mind that at some point you'll need to change to the 1.1 API, and you may need to move sooner to get features you want. As Rich mentioned, 1.1 has some improvements regarding random seeding, so it may be worth doing that now.

Re: PEM_write_bio_RSAPrivateKey assure Randomness of PK

On 23. maí 2018, at 10:08 f.h., redpath <[hidden email]> wrote:
> SO if I add this RAND usage below, em I seeding to assure a different RSA key
> pair each time run of creating a RSA pair.
>
> I would certainly replace the time with the UUID of the device to be unique
> to the device. You would have to acquire the device to know the seeding. Hey keep the Time
> one too.

Attempting to provide a more useful response ...

That is the right way to add entropy to the pool, but (as everyone else has said) neither the current time nor the device's UUID provide enough entropy to satisfy any cryptographic requirements. Adding them to the random pool won't hurt, but you should set the entropy-estimate argument equal to zero (like you did in your example).

Depending on your OpenSSL version *and the platform it's running on*, OpenSSL may automatically seed the random pool from the platform's random-number source(s). It does this by calling RAND_poll(), which is documented in the same manual page as RAND_add(). So, normally you do not need to worry about explicitly seeding the random number generator.

However, if you're running on an embedded device, or running immediately after bootup, or some other situation in which OpenSSL can't get good entropy from the system, you may need to figure out how to supply some yourself. That's pretty difficult to do.