Re: Request for cryptographic mechanisms used in PostgreSQL

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 <nico(at)cryptonector(dot)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
> --
>