I’m not quite sure why I was included in this thread, I am not interested in this topic. Kindly remove me from any future emails.
Regards, Enrique On Sat, 21 Mar 2026 at 19:44, Javier Gutierrez-Maturana sanchez < [email protected]> wrote: > > > 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. > >
