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
session.
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:
http://www.postgresql.org/mailpref/pgsql-hackers
