Re: User functions for building SCRAM secrets - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: User functions for building SCRAM secrets
Date
Msg-id 3d91e3c6-affb-2749-9c29-6d7071ac3ba9@enterprisedb.com
Whole thread Raw
In response to Re: User functions for building SCRAM secrets  (Jacob Champion <jchampion@timescale.com>)
Responses Re: User functions for building SCRAM secrets
List 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()).



pgsql-hackers by date:

Previous
From: David Christensen
Date:
Subject: Re: [PATCHES] Post-special page storage TDE support
Next
From: Andres Freund
Date:
Subject: Re: Non-emergency patch for bug #17679