Subject: Re: Request for cryptographic mechanisms used in PostgreSQL

From: Erik Wienhold <[email-masked]>
Date: Tue, 20 Jan 2026 11:51:35 +0100

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

---

From: [email-masked]
Date: Tue, 20 Jan 2026 11:03:25 -0800

I hope you will consider contributing the finished document back to Postgres, if the core team is interested. This sort of documentation would be very helpful for other organizations, even if they must update it for newer versions.