Thread: [PATCH] using arc4random for strong randomness matters.
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.
Attachment
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:
This is neat. Apparently, it's useable on Linux with a gizmo calledOn 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.
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
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:
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
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
Re: [PATCH] using arc4random for strong randomness matters.
From
ilmari@ilmari.org (Dagfinn Ilmari Mannsåker)
Date:
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 withthe 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.
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 Mannsåker) 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.
regards, tom lane
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