[PATCH] using arc4random for strong randomness matters.

On Tue, Nov 21, 2017 at 9:08 PM, David CARLIER <devnexen@gmail.com> wrote:

Motivation :
- Using fail-safe, file descriptor free solution on *BSD and Darwin system
- Somehow avoiding at the moment FreeBSD as it still uses RC4 (seemingly
updated to Chacha20 for FreeBSD 12.0 and eventually backported later on).
- For implementation based on Chacha* it is known to be enough fast for the
purpose.
- make check passes.

This looks like a good idea to me at quick glance. Please make sure to
register it in the next commit fest if yo uwould like to get feedback
about this feature:
https://commitfest.postgresql.org/16/
--
Michael

On Tue, Nov 21, 2017 at 12:08:46PM +0000, David CARLIER wrote:

Hello,

This is my first small personal contribution.

Motivation :
- Using fail-safe, file descriptor free solution on *BSD and Darwin system
- Somehow avoiding at the moment FreeBSD as it still uses RC4 (seemingly
updated to Chacha20 for FreeBSD 12.0 and eventually backported later on).
- For implementation based on Chacha* it is known to be enough fast for the
purpose.
- make check passes.

Hope it is good.

Thanks in advance.

This is neat. Apparently, it's useable on Linux with a gizmo called
libbsd. Would it be worth it to test for that library on that
platform?

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

I m not against as such that depends of the implementation but I ve seen in
quick glance it s RC4 ?

Regards.

On 22 November 2017 at 15:37, David Fetter <david@fetter.org> wrote:

David CARLIER <devnexen@gmail.com> writes:

I m not against as such that depends of the implementation but I ve seen in
quick glance it s RC4 ?

More generally, why should we bother with an additional implementation?
Is this better than /dev/urandom, and if so why?

regards, tom lane

Basically the call never fails, always generating high quality random data
(especially the implementations based on Chacha* family, RC4 has
predictability issues), there is no need of a file descriptor.

On 22 November 2017 at 16:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Hi,

Please don't top-quote on postgres mailing lists.

On 2017-11-22 16:16:35 +0000, David CARLIER wrote:

David CARLIER <devnexen@gmail.com> writes:

I m not against as such that depends of the implementation but I ve seen

in

quick glance it s RC4 ?

More generally, why should we bother with an additional implementation?
Is this better than /dev/urandom, and if so why?

Basically the call never fails, always generating high quality random data
(especially the implementations based on Chacha* family, RC4 has
predictability issues), there is no need of a file descriptor.

I don't really see much benefit in those properties for postgres
specifically. Not needing an fd is nice for cases where you're not
guaranteed to have access to a filesystem, but postgres isn't going to
work in those cases anyway.

Greetings,

Andres Freund

Tom Lane <tgl@sss.pgh.pa.us> writes:

David CARLIER <devnexen@gmail.com> writes:

I m not against as such that depends of the implementation but I ve seen in
quick glance it s RC4 ?

arc4random uses ChaCha20 since OpenBSD 5.5 (and libbsd 0.8.0 on Linux).
It uses getentropy(2) to seed itself at regular intervals and at fork().

http://man.openbsd.org/arc4random.3

More generally, why should we bother with an additional implementation?
Is this better than /dev/urandom, and if so why?

If what is wanted is something more like /dev/urandom, one can call
getentropy(2) (or on Linux, getrandom(2)) directly, which avoids having
to open the device file each time.

http://man.openbsd.org/getentropy.2
https://manpages.debian.org/stretch/manpages-dev/getrandom.2.en.html

- ilmari
--
"The surreality of the universe tends towards a maximum" -- Skud's Law
"Never formulate a law or axiom that you're not prepared to live with
the consequences of." -- Skud's Meta-Law

On November 22, 2017 8:51:07 AM PST, ilmari@ilmari.org wrote:

If what is wanted is something more like /dev/urandom, one can call
getentropy(2) (or on Linux, getrandom(2)) directly, which avoids having
to open the device file each time.

What does that buy us for our usages?

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

ilmari@ilmari.org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:

Tom Lane <tgl@sss.pgh.pa.us> writes:

More generally, why should we bother with an additional implementation?
Is this better than /dev/urandom, and if so why?

If what is wanted is something more like /dev/urandom, one can call
getentropy(2) (or on Linux, getrandom(2)) directly, which avoids having
to open the device file each time.

I dunno, it seems like this is opening us to a new set of portability
hazards (ie, sub-par implementations of arc4random) with not much gain to
show for it.

IIUC, what this code actually does is reseed itself from /dev/urandom
every so often and work from a PRNG in between. That's not a layer that
we need, because the code on top is already designed to cope with the
foibles of /dev/urandom --- or, to the extent it isn't, that's something
we have to fix anyway. So it seems like having this optionally in place
just reduces what we can assume about the randomness properties of
pg_strong_random output, which doesn't seem like a good idea.

regards, tom lane

I dunno, it seems like this is opening us to a new set of portability
hazards (ie, sub-par implementations of arc4random) with not much gain to
show for it.

Hence I reduced to three platforms only.

IIUC, what this code actually does is reseed itself from /dev/urandom
every so often and work from a PRNG in between. That's not a layer that
we need, because the code on top is already designed to cope with the
foibles of /dev/urandom --- or, to the extent it isn't, that's something
we have to fix anyway. So it seems like having this optionally in place
just reduces what we can assume about the randomness properties of
pg_strong_random output, which doesn't seem like a good idea.

That I admit these are valid points.

Cheers.

David, all,

* David CARLIER (devnexen@gmail.com) wrote:

IIUC, what this code actually does is reseed itself from /dev/urandom
every so often and work from a PRNG in between. That's not a layer that
we need, because the code on top is already designed to cope with the
foibles of /dev/urandom --- or, to the extent it isn't, that's something
we have to fix anyway. So it seems like having this optionally in place
just reduces what we can assume about the randomness properties of
pg_strong_random output, which doesn't seem like a good idea.

That I admit these are valid points.

Based on the discussion, it looks like this patch should be marked as
'Rejected', so I've gone ahead and done that.

We can reopen it if that's incorrect for some reason.

Thanks!

Stephen