| From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
|---|---|
| To: | Jacob Champion <jchampion(at)timescale(dot)com>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Michael Paquier <michael(at)paquier(dot)xyz>, Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org> |
| Subject: | Re: User functions for building SCRAM secrets |
| Date: | 2022-11-08 20:26:56 |
| Message-ID: | 3d91e3c6-affb-2749-9c29-6d7071ac3ba9@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 04.11.22 21:39, Jacob Champion wrote:
> It seems to me that the use case here is extremely similar to the one
> being tackled by Peter E's client-side encryption [1]. People want to
> write SQL to perform a cryptographic operation using a secret, and
> then send the resulting ciphertext (or in this case, a one-way hash)
> to the server, but ideally the server should not actually have the
> secret.
It might be possible, but it's a bit of a reach. For instance, there
are no keys and no decryption associated with this kind of operation.
> I don't think it's helpful for me to try to block progress on this
> patchset behind the other one. But is there a way for me to help this
> proposal skate in the same general direction? Could Peter's encryption
> framework expand to fit this case in the future?
We already have support in libpq for doing this (PQencryptPasswordConn()).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-11-08 20:31:17 | Re: Non-emergency patch for bug #17679 |
| Previous Message | David Christensen | 2022-11-08 20:07:34 | Re: [PATCHES] Post-special page storage TDE support |