MIME-Version: 1.0
References: <CAA5LiFbFsaE1qT+iDtRf0769HG7nFuGzPDa9AJwTzEauNK8J=g@mail.gmail.com>
 <aW/ftSIGMMXsCzPU@ubby> <CAA5LiFZFEbCMv39cbCv2Qp2kxev+QVeeohq13-ukdO=EsGNUBg@mail.gmail.com>
In-Reply-To: <CAA5LiFZFEbCMv39cbCv2Qp2kxev+QVeeohq13-ukdO=EsGNUBg@mail.gmail.com>
From: Ron Johnson <ronljohnsonjr@gmail.com>
Date: Wed, 21 Jan 2026 16:40:01 -0500
Message-ID: <CANzqJaD_K+MnVHFOmgkKfCVt7F4gEV=iCgxJ=f5FTebXfYmSRw@mail.gmail.com>
Subject: Re: Request for cryptographic mechanisms used in PostgreSQL
To: pgsql-general <pgsql-general@postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000d487c30648ecc43e"
Archived-At: <https://www.postgresql.org/message-id/CANzqJaD_K%2BMnVHFOmgkKfCVt7F4gEV%3DiCgxJ%3Df5FTebXfYmSRw%40mail.gmail.com>
Precedence: bulk

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

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=E2=80=AFAM ManiR <mani.retnaswamy@gmail.com> w=
rote:

> 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 t=
he
> 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.=
com>
> 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
>> --
>>
>

--=20
Death to <Redacted>, and butter sauce.
Don't boil me, I'm still alive.
<Redacted> lobster!

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

<div dir=3D"ltr"><div>You can&#39;t write a document about your own prod sy=
stems without knowing what (if any!) cryptography=C2=A0<i>your</i>=C2=A0pro=
d systems use.</div><div><br></div><div dir=3D"ltr">On Wed, Jan 21, 2026 at=
 1:27=E2=80=AFAM ManiR &lt;<a href=3D"mailto:mani.retnaswamy@gmail.com">man=
i.retnaswamy@gmail.com</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_=
quote_container"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr"><p>Hi All,</p><p>Thank you for the responses and suggestions so fa=
r.</p><p>We understand the suggestion to use an LLM as a starting point; ho=
wever, for our compliance and audit requirements, we would like to ensure t=
hat the resulting CBOM is technically accurate and well-grounded in Postgre=
SQL=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 similar crypto=
graphic inventories</strong> available for PostgreSQL (even informal or com=
munity-created ones), and</p></li><li><p>what would be the <strong>recommen=
ded approach or steps</strong> to identify and document PostgreSQL=E2=80=99=
s cryptographic mechanisms accurately.</p></li></ul><p>If anyone has previo=
usly undertaken a <strong>similar exercise</strong> (CBOM, crypto inventory=
, or security documentation) for PostgreSQL, any guidance, references, or d=
ocumentation outlining the <strong>process followed</strong> would be great=
ly 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"><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@cryptonector.com" target=3D"_blank">nic=
o@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(204,204,204);=
padding-left:1ex">On Tue, Jan 20, 2026 at 02:47:36PM +0530, ManiR 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>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr">Death to &lt;Redacted&gt;, and butter sauce.<div=
>Don&#39;t boil me, I&#39;m still alive.<br><div><div>&lt;Redacted&gt; lobs=
ter!</div></div></div></div></div></div>

--000000000000d487c30648ecc43e--