MIME-Version: 1.0
References: <CAA5LiFbFsaE1qT+iDtRf0769HG7nFuGzPDa9AJwTzEauNK8J=g@mail.gmail.com>
 <aW/ftSIGMMXsCzPU@ubby>
In-Reply-To: <aW/ftSIGMMXsCzPU@ubby>
From: ManiR <mani.retnaswamy@gmail.com>
Date: Wed, 21 Jan 2026 11:57:36 +0530
Message-ID: <CAA5LiFZFEbCMv39cbCv2Qp2kxev+QVeeohq13-ukdO=EsGNUBg@mail.gmail.com>
Subject: Re: Request for cryptographic mechanisms used in PostgreSQL
To: Nico Williams <nico@cryptonector.com>
Cc: pgsql-general@postgresql.org
Content-Type: multipart/alternative; boundary="000000000000d2a2dc0648e00579"
Archived-At: <https://www.postgresql.org/message-id/CAA5LiFZFEbCMv39cbCv2Qp2kxev%2BQVeeohq13-ukdO%3DEsGNUBg%40mail.gmail.com>
Precedence: bulk

--000000000000d2a2dc0648e00579
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=
=80=99s
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=E2=80=99s 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=E2=80=AFAM Nico Williams <nico@cryptonector.co=
m> 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
> --
>

--000000000000d2a2dc0648e00579
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>Hi All,</p><p>Thank you for the responses and suggestio=
ns so far.</p><p>We understand the suggestion to use an LLM as a starting p=
oint; however, for our compliance and audit requirements, we would like to =
ensure that the resulting CBOM is technically accurate and well-grounded in=
 PostgreSQL=E2=80=99s actual behavior.</p><p>Could you please let us know:<=
/p><ul><li><p>whether there are any <strong>existing sample CBOMs or simila=
r cryptographic inventories</strong> available for PostgreSQL (even informa=
l or community-created ones), and</p></li><li><p>what would be the <strong>=
recommended approach or steps</strong> to identify and document PostgreSQL=
=E2=80=99s cryptographic mechanisms accurately.</p></li></ul><p>If anyone h=
as previously undertaken a <strong>similar exercise</strong> (CBOM, crypto =
inventory, or security documentation) for PostgreSQL, any guidance, referen=
ces, or documentation outlining the <strong>process followed</strong> would=
 be greatly appreciated.</p><p>Thank you again for your time and help.</p><=
p>Regards,</p><p>Manikandan R</p><br></div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Jan 21, =
2026 at 1:34=E2=80=AFAM Nico Williams &lt;<a href=3D"mailto:nico@cryptonect=
or.com">nico@cryptonector.com</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex">On Tue, Jan 20, 2026 at 02:47:36PM +0530, Mani=
R wrote:<br>
&gt; We would like your guidance on the *cryptographic mechanisms used by<b=
r>
&gt; PostgreSQL*, including:<br>
<br>
FYI this is the sort of thing where LLMs shine.=C2=A0 I would start by aski=
ng<br>
an LLM to write this and then I&#39;d have expert humans review it.<br>
<br>
Keep in mind that some of the cryptographic mechanism/algorithm usage is<br=
>
transitive via PostgreSQL&#39;s dependencies (e.g., SASL, GSS-API, TLS), bu=
t<br>
you might not be interested in expanding that (since you might want to<br>
do separate CBOMs for those.<br>
<br>
Keep in mind that some uses are not actually uses, like the PG crypto<br>
extension, which makes cryptography available to PG _applications_.<br>
<br>
You should also look at options to _not_ use cryptographic mechanisms.<br>
I.e., options to use cleartext protocols.=C2=A0 Obviously it&#39;s much wor=
se to<br>
have a cleartext protocol than one that uses, say, 1DES, even though<br>
1DES is so weak as to be useles.=C2=A0 Often auditors have a blind spot her=
e.<br>
<br>
And it&#39;s important not to treat the presence of, say, MD5 as fatal when=
<br>
it&#39;s not being used for security-critical purposes.<br>
<br>
IMO,<br>
<br>
Nico<br>
-- <br>
</blockquote></div>

--000000000000d2a2dc0648e00579--