Обсуждение: Request for cryptographic mechanisms used in PostgreSQL
Hi PostgreSQL community,
As part of a security documentation update, we are preparing a Cryptographic Bill of Materials (CBOM) to document the cryptographic mechanisms used by the services deployed in our environment.
We would like your guidance on the cryptographic mechanisms used by PostgreSQL, including:
The types of cryptographic mechanisms involved (for example, TLS/SSL for client-server communication, authentication mechanisms, password hashing, replication security, encryption at rest where applicable)
The cryptographic algorithms and protocols used
The source or storage location of cryptographic material (for example, configuration files, certificates, private keys, system catalogs, or external key management systems)
The purpose of each mechanism (for example, data-in-transit encryption, authentication, access control, replication security)
Our goal is to accurately document PostgreSQL’s cryptographic controls for compliance and audit purposes. This request is for documentation clarity only and is not related to vulnerability disclosure.
Any clarification or references to official PostgreSQL documentation would be greatly appreciated.
Thank you for your time and support.
On 2026-01-20 10:17 +0100, ManiR wrote: > As part of a security documentation update, we are preparing a *Cryptographic > Bill of Materials (CBOM)* to document the cryptographic mechanisms used by > the services deployed in our environment. > > We would like your guidance on the *cryptographic mechanisms used by > PostgreSQL*, including: > > - > > The *types of cryptographic mechanisms* involved (for example, TLS/SSL > for client-server communication, authentication mechanisms, password > hashing, replication security, encryption at rest where applicable) > - > > The *cryptographic algorithms and protocols* used > - > > The *source or storage location* of cryptographic material (for example, > configuration files, certificates, private keys, system catalogs, or > external key management systems) > - > > The *purpose* of each mechanism (for example, data-in-transit > encryption, authentication, access control, replication security) > > Our goal is to accurately document PostgreSQL’s cryptographic controls > for *compliance > and audit purposes*. This request is for documentation clarity only and is *not > related to vulnerability disclosure*. > > Any clarification or references to official PostgreSQL documentation would > be greatly appreciated. Some links to get you going: https://www.postgresql.org/docs/current/encryption-options.html https://www.postgresql.org/docs/current/ssl-tcp.html https://www.postgresql.org/docs/current/gssapi-enc.html https://www.postgresql.org/docs/current/ssh-tunnels.html https://www.postgresql.org/docs/current/client-authentication.html https://www.postgresql.org/docs/current/libpq-ssl.html https://www.postgresql.org/docs/current/sasl-authentication.html https://www.postgresql.org/docs/current/pgcrypto.html -- Erik Wienhold
On 2026-01-20 10:17 +0100, ManiR wrote:As part of a security documentation update, we are preparing a *Cryptographic
Bill of Materials (CBOM)* to document the cryptographic mechanisms used by
the services deployed in our environment.
We would like your guidance on the *cryptographic mechanisms used by
PostgreSQL*, including:
-
The *types of cryptographic mechanisms* involved (for example, TLS/SSL
for client-server communication, authentication mechanisms, password
hashing, replication security, encryption at rest where applicable)
-
The *cryptographic algorithms and protocols* used
-
The *source or storage location* of cryptographic material (for example,
configuration files, certificates, private keys, system catalogs, or
external key management systems)
-
The *purpose* of each mechanism (for example, data-in-transit
encryption, authentication, access control, replication security)
Our goal is to accurately document PostgreSQL’s cryptographic controls
for *compliance
and audit purposes*. This request is for documentation clarity only and is *not
related to vulnerability disclosure*.
Any clarification or references to official PostgreSQL documentation would
be greatly appreciated.
Some links to get you going:
https://www.postgresql.org/docs/current/encryption-options.html
https://www.postgresql.org/docs/current/ssl-tcp.html
https://www.postgresql.org/docs/current/gssapi-enc.html
https://www.postgresql.org/docs/current/ssh-tunnels.html
https://www.postgresql.org/docs/current/client-authentication.html
https://www.postgresql.org/docs/current/libpq-ssl.html
https://www.postgresql.org/docs/current/sasl-authentication.html
https://www.postgresql.org/docs/current/pgcrypto.html
--
Erik Wienhold
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 --
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 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
--
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@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
--