Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w41Jj-001mvK-0y for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Mar 2026 18:44:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w41Jh-00BIl6-2Q for pgsql-hackers@arkaria.postgresql.org; Sat, 21 Mar 2026 18:44:58 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w41Jh-00BIkx-1N for pgsql-hackers@lists.postgresql.org; Sat, 21 Mar 2026 18:44:57 +0000 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w41Je-00000000Nwg-2YIb for pgsql-hackers@lists.postgresql.org; Sat, 21 Mar 2026 18:44:57 +0000 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-b97e6e48b24so271603766b.2 for ; Sat, 21 Mar 2026 11:44:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774118694; cv=none; d=google.com; s=arc-20240605; b=WVGzkFG7FzL+IzgKroz7F1luyOxbzIU/pkrsMApk6b2G8i1HM4hrNmeXG9Ye4XAEbi XVdqdKqGnK1J+3qNdj7nt1gBoI6uZrIgiPgbhHn+n9rIzPpLlsZAf/ofgvDxmYPkcDui TXJbom55TwtBocbV3wzIgVcuoMd0hgzDnZ/7Lfg6utRiHoaulFLxbM3e1fUuI7tZH11W aWkcMOqeZC8f7EfwMO/QiVrCYlNtPNg3A+iTQK+cROWybxu4fze+BV8OZF3hw+jcltxL pwBOtUNaEMOab/MB1rrcq7V/+F0yfZIrGFZ5l23/IRyX1kX9Wj4IvkFId93rFsVk3uHY fPSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:mime-version:dkim-signature; bh=0ShKXosMU2ScelG2BK8NZdcFYPCTS+5Cl+9KtoHAdZA=; fh=WTDj3FUrFv27xnAdS6/EUqAxUNxDwK64QaUXBYyDC5s=; b=dYRWMj+hknUnhGZlgHpE9tlnt7qw1Ws84lXn/9BYxFJfRmqOiA/2css/nTJWBDexmU qr4lElDzWDgNu5FQyssISr0/aaMjdeouZbM91GBGnFPKpvbIh67s9JPjGDW60Z5HQNl5 45l/J+2dvfh37oJbAHuMCrrEdthl49x1igvZX6/t0X5En5LLXV6UW8ylVrcsdX1vzfRx cCrIj4grXhYnUL7KyLyrzj5+7ol5EhR8vtE3qgPVERSso0Y57EihJDF6j6dE2mwjeByc aP6x01VcjSjWUKp/8+2VX1gSmIBRG5k0yF2SsSApaDDLrnM/kq7O3hzBgCo73r/HrDe2 6DfQ==; darn=lists.postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1774118694; x=1774723494; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=0ShKXosMU2ScelG2BK8NZdcFYPCTS+5Cl+9KtoHAdZA=; b=WhS2t5vAdsq/7ox5vo6kahG2lif8dP7mHs9M9+w1w/NqJEDAFOBqJty7l3r5fsxfKJ UXwoiOVQIHessCTxTzp/+biDjd9UgqnitZViqkuuHsYo+vFXu/vzzDUXFW8t4xeAVUUT sRTqtS5xAvkJo5YhdUEGLQvBFAn4J+xynj8HzpkVB/sKrbMvbxFtjcprSBy6hw4D6YHU f6QEn0jaf1sXwks71mdQTTwnJMDl7VjV60rcVKyW7OD3bEIc5BwLoYmQ0S+9H62imGCc WkNMNzyo3RSomH+DUEeaU0B7UA/t59c46RpHNXt88jPKbAPg108+C2eD9IHUhtgL4rWA RfzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774118694; x=1774723494; h=to:subject:message-id:date:from:mime-version:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0ShKXosMU2ScelG2BK8NZdcFYPCTS+5Cl+9KtoHAdZA=; b=DqaZMIw5cv2olxJSxcbSbjcemys0ffXm7rLKb9Bgf7RqWHMYpZAhSPVpnrz31BbGIy BsMMaH6N4E7VgGaVNm8RrMJTjSQ7rMNwqFgeSvlUL/xrjPq/bLJn+FmxaN8vijEv6LjH HGuittCaOnXwe6tWIaJB1E7Rr8MvKBmYF/aZb7/qtFX7kH562aifzolAMQ16Wu9MyFah zCZjyljgHVPX7Y63nhrUsDFlhFN1IPRLzBL3Tfjy/WjZmzxNn+BMPPpFZYt5I8qBM0Aq CDjQnNvr5TPEAHQLqP6WB0Pdfv6Yn7n5v2CSzDCn70Oqej2/FPgr5gTTi5gKwz2WDlKF XZlA== X-Gm-Message-State: AOJu0YwS1h2xsKqtp2kz9EwXn545UxAosopt33PGCYppaTT4nC1Nyod4 fAczI92MCit2QwygXgjfni6jBNX8GK/fX1MQhWA0k04Ga9+HWitaG5UBSOWuF1iJtH+Rvc/b+y8 ArPYOgV1aLSL0WFoVBKvjmrPaWmQuw8b1DhV8 X-Gm-Gg: ATEYQzwBnRqU3MLidEb2xRbofeqS0fmCRr9mZ/m4QuFqMZGTDZY9yT4O2UobM2vPZWA ofEL7ryD2yD9/T13Ht33JJBqEnnW7AfLiqVachxlPatuYJxIj0H5b2oD+N+ge4x88CsH/v1K+9C FRtOY+MVLRpI76yqXD3ekQmSV66Vwn4eU8ioeVhm/E4fmfuHeDCeJ7vQy42+aFpHDpRcrMKKY/J nakb+aKg9RPu+i1N/ZRymsakQITX2VZOiWeKTP3VWpVyLGslp8PhqLMgsovxg88Cr0zc3zLNkhh CansDUiEPvZDQZttzPqCi2M/2c3MsvyfgpL3iv+F9W62Gt0YQthILorrouUn83jg/kIWdN3puSd AhaVXLF+6 X-Received: by 2002:a17:907:3e21:b0:b98:5648:e68a with SMTP id a640c23a62f3a-b985648edd0mr116600966b.36.1774118693662; Sat, 21 Mar 2026 11:44:53 -0700 (PDT) MIME-Version: 1.0 From: Javier Gutierrez-Maturana sanchez Date: Sat, 21 Mar 2026 19:44:42 +0100 X-Gm-Features: AaiRm52si-qPYg6sbhumu5W06SU7m_mE-nLIZdJeDnuItP0_ZOkGcmcEgW-hn_8 Message-ID: Subject: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL To: pgsql-hackers@lists.postgresql.org, Enrique Soriano , Gorka Guardiola Content-Type: multipart/alternative; boundary="0000000000008672ea064d8d32ce" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000008672ea064d8d32ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello PostgreSQL community, I would like to start a discussion regarding the feasibility of decoupling our current TLS implementation to allow for alternative cryptographic backends, specifically **Botan** (via its C wrapper). While OpenSSL is the current standard, the "rules of the game" in software engineering are changing. The advent of advanced AI-assisted development tools now provides the technical viability to undertake significant refactorings=E2=80=94such as abstracting the network security layer=E2=80= =94with much higher precision and lower overhead than in the past. The primary motivation for adding Botan support is **compliance and architectural flexibility**: 1. **Regulatory Requirements:** In jurisdictions like Spain, the **CCN (Centro Criptol=C3=B3gico Nacional)** sets specific standards for cryptogra= phic modules. Having an alternative like Botan facilitates certification in these restricted environments. 2. **Architectural Robustness:** A provider-agnostic TLS layer makes PostgreSQL more resilient to library-specific vulnerabilities or licensing changes. 3. **Modern Integration:** Using Botan's C wrappers allows the engine to benefit from a modern C++ cryptographic core while maintaining the project's C-based architecture. I am interested in knowing the community's stance on abstracting `be-secure-openssl.c` into a more generic interface. Best regards, [Tu Nombre] --- ### Appendix: Proof of Concept - Proxy Model with Botan To validate the viability of Botan in high-security environments without depending on OpenSSL's native integration, I have developed a reference implementation available at: =F0=9F=91=89 [ https://github.com/jgmatu/management-sensors](https://github.com/jgmatu/man= agement-sensors) **Architectural Model:** In this project, I implemented a **Quantum-Safe Proxy** that acts as a bridge between non-PQC clients and the core system. Key features of this model include: * **Decoupled TLS Engine:** Using `QuantumSafeTlsEngine` (based on Botan TLS v1.3) to handle all secure handshakes independently of the application logic. * **Reactive Event Bus:** Utilizing PostgreSQL's `LISTEN/NOTIFY` mechanism to manage state and configurations without direct coupling between the server and the controllers. * **Post-Quantum Ready:** Demonstrating that Botan can provide PQC (Post-Quantum Cryptography) algorithms today, which is a requirement increasingly demanded by national security agencies like the CCN. This proxy model proves that Botan is not only a viable alternative but also provides advanced features that are currently difficult to implement with a hard dependency on OpenSSL. --0000000000008672ea064d8d32ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


<= div dir=3D"auto">Hello PostgreSQL community,

I would like to start a discussion regarding the feasi= bility of decoupling our current TLS implementation to allow for alternativ= e cryptographic backends, specifically **Botan** (via its C wrapper).
=

While OpenSSL is the current = standard, the "rules of the game" in software engineering are cha= nging. The advent of advanced AI-assisted development tools now provides th= e technical viability to undertake significant refactorings=E2=80=94such as= abstracting the network security layer=E2=80=94with much higher precision = and lower overhead than in the past.

The primary motivation for adding Botan support is **complianc= e and architectural flexibility**:

1. **Regulatory Requirements:** In jurisdictions like Spain, th= e **CCN (Centro Criptol=C3=B3gico Nacional)** sets specific standards for c= ryptographic modules. Having an alternative like Botan facilitates certific= ation in these restricted environments.
2. **Archit= ectural Robustness:** A provider-agnostic TLS layer makes PostgreSQL more r= esilient to library-specific vulnerabilities or licensing changes.
3. **Modern Integration:** Using Botan's C wrappers all= ows the engine to benefit from a modern C++ cryptographic core while mainta= ining the project's C-based architecture.

I am interested in knowing the community's stance= on abstracting `be-secure-openssl.c` into a more generic interface.
<= div dir=3D"auto">
Best regards,

[Tu Nombre]

<= /div>
---

### Appendix: Proof of Concept - Proxy Model with Botan

To validate the viability of Botan in hi= gh-security environments without depending on OpenSSL's native integrat= ion, I have developed a reference implementation available at:
=F0=9F=91=89 [https://github.com/jg= matu/management-sensors](https://github.com/jgmatu/management-sensors)<= /div>

**Architectural Model:**=
In this project, I implemented a **Quantum-Safe Pro= xy** that acts as a bridge between non-PQC clients and the core system. Key= features of this model include:

* **Decoupled TLS Engine:** Using `QuantumSafeTlsEngine` (based o= n Botan TLS v1.3) to handle all secure handshakes independently of the appl= ication logic.
* **Reactive Event Bus:** Utilizing P= ostgreSQL's `LISTEN/NOTIFY` mechanism to manage state and configuration= s without direct coupling between the server and the controllers.
* **Post-Quantum Ready:** Demonstrating that Botan can provid= e PQC (Post-Quantum Cryptography) algorithms today, which is a requirement = increasingly demanded by national security agencies like the CCN.

This proxy model proves that Bota= n is not only a viable alternative but also provides advanced features that= are currently difficult to implement with a hard dependency on OpenSSL.

--0000000000008672ea064d8d32ce--