On 09/27/2016 04:19 PM, Michael Paquier wrote:
On Tue, Sep 27, 2016 at 9:01 PM, Heikki Linnakangas <hlinn...@iki.fi> wrote:
* A source of random values. This currently uses PostmasterRandom()
similarly to how the MD5 salt is generated, in the server, but plain old
random() in the client. If built with OpenSSL, we should probably use
RAND_bytes(). But what if the client is built without OpenSSL? I believe the
protocol doesn't require cryptographically strong randomness for the nonces,
i.e. it's OK if they're predictable, but they should be different for each

And what if we just replace PostmasterRandom()? pgcrypto is a useful
source of inspiration here. If the server is built with OpenSSL we use
RAND_bytes all the time. If not, let's use /dev/urandom. If urandom is
not there, we fallback to /dev/random. For WIN32, there is
CryptGenRandom(). This could just be done as an independent patch with
a routine in src/common/ for example to allow both frontend and
backend to use it.

Yeah, if built with OpenSSL, we probably should just always use RAND_bytes(). Without OpenSSL, we have to think a bit harder.

The server-side code in the patch is probably good enough. After all, we use the same mechanism for the MD5 salt today.

The libpq-side is not. Just calling random() won't do. We haven't needed for random numbers in libpq before, but now we do. Is the pgcrypto solution portable enough that we can use it in libpq?

Do you think that this is a requirement for this
patch? I think not really for the first shot.

We need something for libpq. We can't just call random(), as that's not random unless you also do srandom(), and we don't want to do that because the application might have a different idea of what the seed should be.

- Heikki

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to