postgres.email
❮

Request for cryptographic mechanisms used in PostgreSQL

  • Jump to comment-1
    ManiR<mani.retnaswamy@gmail.com>
    Jan 20, 2026, 9:57 AM UTC
    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.
    View in PostgreSQL Archives →
    • Jump to comment-1
      Nico Williams<nico@cryptonector.com>
      Jan 20, 2026, 8:04 PM UTC
      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
      --
      View in PostgreSQL Archives →
      • Jump to comment-1
        ManiR<mani.retnaswamy@gmail.com>
        Jan 21, 2026, 6:27 AM UTC
        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
        --
        View in PostgreSQL Archives →
        • Jump to comment-1
          Ron Johnson<ronljohnsonjr@gmail.com>
          Jan 21, 2026, 9:40 PM UTC
          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 AM ManiR <mani.retnaswamy@gmail.com> wrote:
          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
          --
          --
          Death to <Redacted>, and butter sauce.
          Don't boil me, I'm still alive.
          <Redacted> lobster!
          View in PostgreSQL Archives →
    • Jump to comment-1
      Erik Wienhold<ewie@ewie.name>
      Jan 20, 2026, 10:51 AM UTC
      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
      View in PostgreSQL Archives →