public inbox for [email protected]
help / color / mirror / Atom feedFrom: Javier Gutierrez-Maturana sanchez <[email protected]>
To: [email protected]
To: Enrique Soriano <[email protected]>
To: Gorka Guardiola <[email protected]>
Subject: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
Date: Sat, 21 Mar 2026 19:44:42 +0100
Message-ID: <CA+5Zhp62fb6WMyzm1ZpKiYw3Pbtrjb=Vehug4xKmNeovpNjaCw@mail.gmail.com> (raw)
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—such as abstracting the network security layer—with 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ógico Nacional)** sets specific standards for cryptographic
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:
👉 [
https://github.com/jgmatu/management-sensors](https://github.com/jgmatu/management-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.
view thread (4+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
In-Reply-To: <CA+5Zhp62fb6WMyzm1ZpKiYw3Pbtrjb=Vehug4xKmNeovpNjaCw@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox