| From: | Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | Joe Conway <mail(at)joeconway(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Support getrandom() for pg_strong_random() source |
| Date: | 2025-10-09 15:20:26 |
| Message-ID: | CAOYmi+kRVoiX5hTFo_4+a5aOFd50kL+feVEe7j_-8qYyZNfrSw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Oct 7, 2025 at 1:26 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> Using a UUID as salt would perhaps be one scenario which would turn the RNG
> used for UUIDs into security functionality according to the FIPS definitions?
I don't know. One might idly hope that using a UUID for a salt would
itself be a FIPS violation :D but it's probably not.
I guess there's a bit of a procedural question bundled in with this
(that is getting ever further afield of Sawada-san's proposal). If we
happen to use a CSPRNG to generate some sort of non-security-related
output, and then someone uses that output to seed some crypto, do we
consider ourselves on the hook if we change the implementation? The
UUID RFCs are pretty clear that you're not supposed to treat them as
unguessable even if an ideal implementation is, and I'm starting to
agree with Joe that we need to document that ourselves.
--Jacob
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2025-10-09 15:21:56 | Re: Support getrandom() for pg_strong_random() source |
| Previous Message | Tom Lane | 2025-10-09 15:19:14 | Re: Add RESPECT/IGNORE NULLS and FROM FIRST/LAST options |