public inbox for [email protected]
help / color / mirror / Atom feedRe: Request for cryptographic mechanisms used in PostgreSQL
3+ messages / 3 participants
[nested] [flat]
* Re: Request for cryptographic mechanisms used in PostgreSQL
@ 2026-01-20 20:04 Nico Williams <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Nico Williams @ 2026-01-20 20:04 UTC (permalink / raw)
To: ManiR <[email protected]>; +Cc: pgsql-general
On Tue, Jan 20, 2026 at 02:47:36PM +0530, ManiR wrote:
> We would like your guidance on the *cryptographic mechanisms used by
> PostgreSQL*, including:
FYI this is the sort of thing where LLMs shine. I would start by asking
an LLM to write this and then I'd have expert humans review it.
Keep in mind that some of the cryptographic mechanism/algorithm usage is
transitive via PostgreSQL's dependencies (e.g., SASL, GSS-API, TLS), but
you might not be interested in expanding that (since you might want to
do separate CBOMs for those.
Keep in mind that some uses are not actually uses, like the PG crypto
extension, which makes cryptography available to PG _applications_.
You should also look at options to _not_ use cryptographic mechanisms.
I.e., options to use cleartext protocols. Obviously it's much worse to
have a cleartext protocol than one that uses, say, 1DES, even though
1DES is so weak as to be useles. Often auditors have a blind spot here.
And it's important not to treat the presence of, say, MD5 as fatal when
it's not being used for security-critical purposes.
IMO,
Nico
--
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Request for cryptographic mechanisms used in PostgreSQL
@ 2026-01-21 06:27 ManiR <[email protected]>
parent: Nico Williams <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: ManiR @ 2026-01-21 06:27 UTC (permalink / raw)
To: Nico Williams <[email protected]>; +Cc: pgsql-general
Hi All,
Thank you for the responses and suggestions so far.
We understand the suggestion to use an LLM as a starting point; however,
for our compliance and audit requirements, we would like to ensure that the
resulting CBOM is technically accurate and well-grounded in PostgreSQL’s
actual behavior.
Could you please let us know:
-
whether there are any *existing sample CBOMs or similar cryptographic
inventories* available for PostgreSQL (even informal or
community-created ones), and
-
what would be the *recommended approach or steps* to identify and
document PostgreSQL’s cryptographic mechanisms accurately.
If anyone has previously undertaken a *similar exercise* (CBOM, crypto
inventory, or security documentation) for PostgreSQL, any guidance,
references, or documentation outlining the *process followed* would be
greatly appreciated.
Thank you again for your time and help.
Regards,
Manikandan R
On Wed, Jan 21, 2026 at 1:34 AM Nico Williams <[email protected]> wrote:
> On Tue, Jan 20, 2026 at 02:47:36PM +0530, ManiR wrote:
> > We would like your guidance on the *cryptographic mechanisms used by
> > PostgreSQL*, including:
>
> FYI this is the sort of thing where LLMs shine. I would start by asking
> an LLM to write this and then I'd have expert humans review it.
>
> Keep in mind that some of the cryptographic mechanism/algorithm usage is
> transitive via PostgreSQL's dependencies (e.g., SASL, GSS-API, TLS), but
> you might not be interested in expanding that (since you might want to
> do separate CBOMs for those.
>
> Keep in mind that some uses are not actually uses, like the PG crypto
> extension, which makes cryptography available to PG _applications_.
>
> You should also look at options to _not_ use cryptographic mechanisms.
> I.e., options to use cleartext protocols. Obviously it's much worse to
> have a cleartext protocol than one that uses, say, 1DES, even though
> 1DES is so weak as to be useles. Often auditors have a blind spot here.
>
> And it's important not to treat the presence of, say, MD5 as fatal when
> it's not being used for security-critical purposes.
>
> IMO,
>
> Nico
> --
>
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Request for cryptographic mechanisms used in PostgreSQL
@ 2026-01-21 21:40 Ron Johnson <[email protected]>
parent: ManiR <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Ron Johnson @ 2026-01-21 21:40 UTC (permalink / raw)
To: pgsql-general
You can't write a document about your own prod systems without knowing what
(if any!) cryptography *your* prod systems use.
On Wed, Jan 21, 2026 at 1:27 AM ManiR <[email protected]> wrote:
> Hi All,
>
> Thank you for the responses and suggestions so far.
>
> We understand the suggestion to use an LLM as a starting point; however,
> for our compliance and audit requirements, we would like to ensure that the
> resulting CBOM is technically accurate and well-grounded in PostgreSQL’s
> actual behavior.
>
> Could you please let us know:
>
> -
>
> whether there are any *existing sample CBOMs or similar cryptographic
> inventories* available for PostgreSQL (even informal or
> community-created ones), and
> -
>
> what would be the *recommended approach or steps* to identify and
> document PostgreSQL’s cryptographic mechanisms accurately.
>
> If anyone has previously undertaken a *similar exercise* (CBOM, crypto
> inventory, or security documentation) for PostgreSQL, any guidance,
> references, or documentation outlining the *process followed* would be
> greatly appreciated.
>
> Thank you again for your time and help.
>
> Regards,
>
> Manikandan R
>
>
> On Wed, Jan 21, 2026 at 1:34 AM Nico Williams <[email protected]>
> wrote:
>
>> On Tue, Jan 20, 2026 at 02:47:36PM +0530, ManiR wrote:
>> > We would like your guidance on the *cryptographic mechanisms used by
>> > PostgreSQL*, including:
>>
>> FYI this is the sort of thing where LLMs shine. I would start by asking
>> an LLM to write this and then I'd have expert humans review it.
>>
>> Keep in mind that some of the cryptographic mechanism/algorithm usage is
>> transitive via PostgreSQL's dependencies (e.g., SASL, GSS-API, TLS), but
>> you might not be interested in expanding that (since you might want to
>> do separate CBOMs for those.
>>
>> Keep in mind that some uses are not actually uses, like the PG crypto
>> extension, which makes cryptography available to PG _applications_.
>>
>> You should also look at options to _not_ use cryptographic mechanisms.
>> I.e., options to use cleartext protocols. Obviously it's much worse to
>> have a cleartext protocol than one that uses, say, 1DES, even though
>> 1DES is so weak as to be useles. Often auditors have a blind spot here.
>>
>> And it's important not to treat the presence of, say, MD5 as fatal when
>> it's not being used for security-critical purposes.
>>
>> IMO,
>>
>> Nico
>> --
>>
>
--
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-01-21 21:40 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-20 20:04 Re: Request for cryptographic mechanisms used in PostgreSQL Nico Williams <[email protected]>
2026-01-21 06:27 ` ManiR <[email protected]>
2026-01-21 21:40 ` Ron Johnson <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox