OpenSSL Conference
To Be Confirmed
We explain what the OpenSSL Software Foundation is and does and what its place is in the governance structure behind delivering the OpenSSL project. We will cover the various things that you can do to get involved whether that’s on a technical or business level and how you can influence the project’s direction. Finally we talk about our mission and how the Foundation delivers it.
To Be Confirmed
The 2024 European elections marked the start of the new 5 year mandate of the European Parliament followed by forming a new political direction of the European Commission. What does this change mean for cryptography and its regulation in Europe? How can encryption be framed as a vital tool to secure fundamental rights in the digital age, rather than as a law enforcement nightmare? The talk will primarily focus on the recent developments in political narratives around securing access to encrypted data by law enforcement authorities, the current European Commission’s plans as presented in ProtectEU: the European Internal Security Strategy, and the impact on privacy and security.
To Be Confirmed
As the cryptographic community rallies behind NIST's post-quantum cryptography (PQC) standardization, one truth is becoming clear: PQC won't succeed in isolation. It must interoperate — across algorithms, libraries, protocols, and real-world infrastructure.
We have embraced this challenge head-on by creating a living interoperability tracker — continuously testing PQC integration across solutions and open-source projects like EJBCA, SignServer, and Bouncy Castle. Working in collaboration with projects such as OpenSSL, WolfSSL, and leading HSM vendors, our goal is clear: to demonstrate that post-quantum cryptography isn’t just theoretical — it’s practical and working today.
This talk will share concrete results from our testing across TLS 1.3, CMS, hybrid certificates, and Hardware Security Modules (HSM) integrations — using LMS, ML-DSA, ML-KEM, and SLH-DSA. We’ll highlight what worked, what broke, and what we’re learning about making PQC truly usable at scale.
Most importantly, we’ll explore how collaboration — with OpenSSL maintainers, IETF hackathons, and standards bodies — is critical to ensuring that the next generation of cryptography is not only secure, but interoperable and practical. We’ll provide practical configuration examples and open-source tools for those ready to start their own PQC journey.
Nowadays people may be curious about how the cryptography market and open-source communities look like. In this session, a brief and concise talk will reveal some interesting facts that can help your business or communities blend into China.
Jon Ericson, Communities Manager with the OpenSSL Foundation, reports on the state of the OpenSSL community as of release 3.6.
For the last 6 years I've been advocating for the adoption of client side encryption, with a zero trust protocol, speaking about its technical nuances and software implementation in several IT conferences in Europe and America. This entered into my life as a broad but imperative business requirement: "avoid data leakage at any cost". I was very glad on having the opportunity to learn more deeply about cryptology and contribute some code for that purpose. However, today I would like to focus on what end-to-end encryption (E2EE) really means and how NIS2 regulation seems to be misinterpreting it. While a huge emphasis is given to E2EE, the same regulation also mentions the need of granting to the government the powers of content surveillance, and these two requirements are inescapably contradictory.
This talk looks at the quantocalypse, and the implications for quantum cryptanalysis using purely evidence-based empirical sources without resorting to fallacies like appeal to authority and sky-is-falling speculation. The result is summarised by the title of the talk.
Most small and mid-sized businesses think security is a “big company problem” until they get hacked, blacklisted, or lose customer trust overnight. And while OpenSSL powers a massive portion of the internet, these same businesses often have no idea what it is or how it affects them.
In this talk, Brandan Payne breaks down the mindset gap between technical professionals and small business owners, and offers three simple shifts to close that gap and promote better adoption of secure practices.
You’ll learn:
/Why the biggest security risk isn’t bad code, it’s communication
/How to position OpenSSL and encryption as a business asset, not a tech hurdle
/A practical framework for educating small teams without overwhelming them
This session is ideal for developers, security engineers, and compliance pros who want to better engage real-world clients, as well as anyone advocating for stronger small business security practices within the OpenSSL ecosystem.
This talk presents a scalable framework for deploying an enterprise Private Certificate Authority (CA) using OpenSSL and cloud-based HSMs. We explore a solution that centralizes certificate lifecycle management—including issuance, monitoring, and automated expiry alerts—while enforcing security through offline key generation with OpenSSL (RSA-2048) and hardware-grade protection via AWS CloudHSM. The design eliminates direct key exposure by leveraging FIPS 140-2 Level 3-validated HSMs and enables self-service workflows with minimal manual intervention. Attendees will learn practical strategies for balancing security, automation, and usability in PKI deployments.
The post-quantum cryptography (PQC) transition is more than a drop-in key exchange replacement—it’s a deep transformation in how cryptographic software is designed, built, and integrated. OpenSSL 3.0 introduced the concept of Providers, a flexible plugin architecture that enables new cryptographic algorithms to be implemented outside of the core library. This opens the door for innovation, modularity—and Rust.
In this session, we introduce Aurora, a third-party OpenSSL provider implemented in Rust as part of the EU-funded QUBIP project. Aurora enables transparent PQC adoption for OpenSSL-based applications, including hybrid certificate validation, algorithm agility, and integration with Rust’s cryptographic ecosystem.
We’ll walk through the motivation behind building a provider in Rust, the challenges we faced (e.g., FFI safety, Provider interface complexity), and how Aurora leverages Rust’s guarantees to offer a robust foundation for cryptographic experimentation and deployment.
The session includes a live demo showing how Aurora can inject PQC algorithms into existing OpenSSL workflows without modifying the application code. We’ll also explore tooling such as openssl-provider-forge, our Rust crate that simplifies authoring and testing custom providers.
Whether you’re maintaining a TLS stack, building HSM software, or researching cryptographic agility, this talk will provide hands-on insight into the real-world journey of enabling PQC inside OpenSSL using modern language tools.
OpenSSL never directly supported accessing hardware modules through PKCS#11. Over the years, the community created various engines for this task, but only with the OpenSSL 3 Store API and with providers integration it became more streamlined, which is when we started working on the pkcs11-provider project [1].
But we did not stop here. From the pkcs11-provider side, we brought the SKEY API to OpenSSL 3.5. We also implemented a new software pkcs11 module kryoptic [2] (using OpenSSL), which closes the circle and we can now use OpenSSL also as a PKCS#11 module.
In this presentation, I would like to talk about the recent development of the PKCS#11 standard, about the development of a pkcs11-provider, and how kryoptic works and what problems it solved for us.
[1] https://github.com/latchset/pkcs11-provider
[2] https://github.com/latchset/kryoptic/
The polar bear is an iconic species at Brno Zoo. It is the only zoo in Europe to have successfully raised five cubs through natural breeding. Building on this success, the zoo aims to continue contributing to the global conservation program for these ambassadors of critically endangered species. To ensure that polar bears can survive in the wild, it is essential—among other measures—to maintain a strong and genetically diverse population in zoological institutions. You can help, too.
Zoos worldwide are evolving into institutions focused on conservation and education, placing strong emphasis on biodiversity—its meaning, its protection, and the role zoos can play. As species loss accelerates due to human activity and climate change, zoos have a unique opportunity to explain complex issues like biodiversity and sustainability in accessible ways. By partnering with the corporate sector, zoos can lead by example—fostering connection with nature, raising awareness of environmental threats, and inspiring action.
TBC
Active Directory environments depend heavily on TLS and X.509 certificates—yet few defenders look at them through the lens of OpenSSL, the Swiss Army knife of cryptographic analysis. Whether it's LDAP over SSL (LDAPS) or certificate-based Kerberos authentication (PKINIT), small certificate misconfigurations can lead to major security exposures.
In this talk, I’ll discuss how to use OpenSSL as your primary tool for breaking, auditing, and hardening Active Directory’s certificate trust chains. We’ll walk through how attackers can abuse weak certificates and TLS configurations using OpenSSL, and how defenders can use those same tools to shut it down.
From real-time LDAPS probes to parsing malicious Kerberos smartcard certs, this session will show you that OpenSSL isn’t just for developers—it’s a penetration tester’s scalpel and a defender’s stethoscope.
This talk revisits the trials and tribulations of writing an OpenSSL provider for a large family of PQC algorithms. In 2021, initially only PQC KEM algorithms were made available by the author but over time signature, hybrid and composite PQC support got added, too. This work could only succeed with the active support by the core OpenSSL team which this talk will provide examples for. In turn, the author also began to contribute back to OpenSSL core some functions enhancing the OpenSSL provider concept, documenting the benefits of a truly open source cooperation.
This talk explains how to solve the private key protection problem for PQC algorithms, in the domain of regulated and certified digital identity wallets, but applicable more generally. EUDI wallets will rely on the abstract components WSCA (Wallet Secure Cryptographic Application) and WSCD (Wallet Secure Cryptographic Device). We show that the use of threshold and thresholdized pre- and postquantum-secure signature schemes in handshake protocols is a viable approach, providing an alternative for the case when hardware support for such schemes will be delayed. We discuss how such schemes can be deployed, and what performance to expect. While hardware solutions usually enjoy government approved security certification status, we show how to achieve the same security assurance level with software-oriented products, which are based on PQC-secure threshold schemes.
OpenSSL Provider's allow for an easy mechanism to include unique cryptographic implementations (from a performance or security standpoint), specific to certain HW configurations, beyond what is in the default OpenSSL provider. As such there are a number of advantages to developing a provider for both the business and developer. In this talk I will cover the advantages and disadvantages of the provider approach along with practical use cases.
We've seen endless examples of cryptographic software that leaks
secret information through timing or has outright bugs for some
inputs. Cryptographic systems end up exploitable in the real world
even without being broken in theory. Often these vulnerabilities
remain undiscovered by the public for many years. The "all bugs are
shallow" philosophy fails for even the simplest cryptographic
computations, and is hopeless when software is made even more
complicated in the pursuit of speed. Are we doomed to a neverending
cycle of attacks and emergency upgrades?
A convincing solution is finally coming together, as illustrated by
DIT from ARM, DOIT from Intel, and s2n-bignum from AWS. This talk will
give examples to illustrate how this solution works.
Chronicles of my journey into the world on Post Quantum Cryptography.
A short few years ago, I was tasked with exploring a plan that would bring Post Quantum Crypto into
Our common cryptographic library. CNSA 2.0 kept on coming up in meetings, the NIST standardization process was in full swing and we needed a plan.
The panic had already started because we were already late. What to do?
This presentation will examine the legal and commercial implications of poor open source and third party code management, including:
The legal basics of open source licensing;
The risks of unknown third part code in proprietary software;
Bad and good dev team habits when using open source;
War stories, including how poor third party code management can kill an M&A deal;
Best practice with open source and third party code management.
This talk presents implementations that match and, where possible, exceed current quantum factorisation records using a VIC-20 8-bit home computer from 1981, an abacus, and a dog. We hope that this work will inspire future efforts to match any further quantum factorisation records, should they arise.
Struggling with cybersecurity compliance? OpenSSL is a powerful ally. This session reveals how OpenSSL underpins vital certifications like FIPS 140-3, directly enabling for example FedRAMP adherence. And how Common Criteria certifications use OpenSSL in a very essential way. We'll explore its use in meeting and testing security requirements, then propose how community collaboration can fast-track evaluations. Finally, get an inside look at how Red Hat leverages OpenSSL for compliance activities, and how Red Hat's customer and partners could leverage (not only) our work.
OpenSSL is the most popular cryptographic library, a cornerstone of secure communication, and its cryptographic internals continue to evolve and therefore deserve scrutiny. In this lightning talk, we present a concise technical overview of how OpenSSL compares to other major libraries in its implementation of elliptic curve cryptography (ECC), based on our analysis using the reverse-engineering tool called pyecsca. We comment on some design decisions, coordinate system choices, and optimizations selected by OpenSSL developers, and how it compares to the broader ecosystem of cryptographic libraries.
We then turn to RSA, where our large-scale analysis reveals subtle, persistent fingerprints in OpenSSL-generated keys. Drawing from our studies published at USENIX and ESORICS, we demonstrate how these fingerprints can be used to attribute keys in the wild, exposing systemic patterns and even detecting unwantedly injected keys, as seen in Estonian electronic IDs in 2017. Moreover, we discuss how our open-source channel tooling can be used to analyze the side-channel security of OpenSSL.
All of this is powered by tools and techniques developed at the Centre for Research on Cryptography and Security (CRoCS) at Masaryk University. We aim to show deep and practical security insights through rigorous tooling and transparency.
Presented by:
Łukasz Chmielewski, Centre for Research on Cryptography and Security (CRoCS), Masaryk University
https://crocs.fi.muni.cz/
Open-source cryptographic libraries like OpenSSL are foundational to the internet’s security—but when misused or misconfigured, they don’t just open the door to cyber threats. They open the door to legal ones. This session explores the collision between technical missteps in cryptography and high-stakes legal exposure, examining how supply chain vulnerabilities, licensing misunderstandings, and implementation failures can escalate into breach reporting obligations, regulatory investigations, and contractual liability. We’ll also unpack how legal teams can support engineering in building stronger risk models and contract guardrails when deploying open-source cryptography.
Cryptography is hard! Protocols are hard! Cyber Security is hard! All these are hard enough on their own and must be done correctly in a single product. But, how do you ensure quality, correctness and stay up to date across a diverse portfolio of products that are deployed globally? Can we have a common library that meets most of our needs? Can we support it (given it's hard)? How do we stay current?
This talk will examine:
1 - Why would one want to attempt this? What are the benefits?
2 - How could someone go about this (some helpful strategies).
3 - Sounds great - what are the pitfalls?
4 - Success stories.
5 - Lessons learned (not success stories).
6 - Conclusion (Is it impossible?)
7 - Questions?
Before OpenSSL 3.5 we implied that symmetric keys are always represented as an array of bytes. Unfortunately, that's not enough for non-extractable symmetric keys.
Since 3.5 we are closing this deficiency.
For more than a decade, pyca/cryptography has been the most widely used cryptography library in the Python ecosystem, and for that entire period, we've relied on OpenSSL to provide core cryptographic algorithms, while also supporting various OpenSSL forks. However, we've also made changes to how we use OpenSSL in that period: we increasingly handle X.509 (including path building and parsing), as well as key parsing and serialization ourselves. This talk will cover lessons learned, and opportunity for improvement in OpenSSL, including API design, performance, and testing.
With its flexible architecture and enhanced performance, OpenSSL 3 has seen increasing adoption across the enterprise software landscape, where stringent requirements for security, modularity, performance, and stability are paramount. As one of the world’s largest enterprise software vendors, Oracle provides a broad portfolio encompassing operating systems, databases, and applications. These offerings support a wide spectrum from small to extremely large environments, operating under diverse loads, use cases, and legacy as well as modern configurations.
Adoption of OpenSSL within such a landscape introduces a range of unique requirements, including cryptographic strength tuning for legacy systems, PKCS#11 support for hardware security modules (HSMs), robust thread safety, extreme connection scalability without memory leakage, application key material injection into the TLS stack, TLS context migration across processes, and strict minimum-load performance expectations. Additionally, support is needed for Java and Microsoft Cryptography Next Generation (CNG) support.
This presentation outlines Oracle’s journey in adopting OpenSSL, and discusses the above challenges, accommodations, and workarounds. Additionally, we will offer recommendations on how OpenSSL 3 can be made easier to adopt for larger enterprise software organizations.
Side-channel attacks are a common threat to cryptographic implementations. Unfortunately, most available tooling to combat this problem has limited usability, especially in black-box testing scenarios. In this talk I will talk about how by performing the testing using statistical best practices we were able to find multiple leaking implementations of cryptographic algorithms in OpenSSL. I'll also talk about how we're applying the lessons learned from testing RSA and ECDSA to testing post-quantum cryptography like ML-KEM.
Since 2014 we see a lot of different forks of OpenSSL project, with various goals and limitations.
The diverging of the OpenSSL forks impacts the application developers - they have to maintain slightly different code paths.
What do we know about the usage of OpenSSL in certified software and devices? Is its prevalence rising or falling? Who uses it? And what versions are used? What else can we learn without having to sign an NDA?
This talk will dive into the certification landscape of Common Criteria and FIPS140, focusing on the role of OpenSSL as a use case to see how much we can learn from publicly available data.
DNSSEC and DANE offer an alternative to the established WebPKI that avoids needing to trust too many third-party CAs. The right party to assert who controls a domain is the parent registry in coördination with the domain registrar; 3rd-party CAs are second-hand observers performing weak trust-on-first-use tests of "domain control".
This talk will cover the preliminaries of DNSSEC and DANE and then explore support for DANE in the OpenSSL API.
With all FIPS 140-2 certificates scheduled to sunset by September 2026, developers and integrators must now transition to the more structured and demanding FIPS 140-3 certification process. This 30-minute session provides a high-level, experience-based overview of the current validation landscape, tailored for technical and compliance teams preparing for engagement with the Cryptographic Module Validation Program (CMVP).
Databases are by nature IO heavy, and in the upcoming version of Postgres we continue to push the IO envelope with the introduction of asynchronous IO infrastructure. As datasets grow, the need for pushing even larger amounts of data across the wire will increase, and with it the performance overhead paid when using TLS connections. In this talk we'll go through how Postgres is using OpenSSL, what sort of bottlenecks we run into, and what our ultimate OpenSSL changelog wishlist would be.
And while at it, can we have a pony too?
Red Hat Enterprise Linux 10.0 shipped with OpenSSL 3.2 and supports hybrid
post-quantum key exchange in TLS and ML-DSA signatures. CentOS 10 Stream, which
will become RHEL 10.1, has already upgraded to OpenSSL 3.5.
Learn how OpenSSL 3's provider architecture allowed Red Hat to bring
post-quantum cryptography to its operating system quickly and migrate to
OpenSSL's own implementation later on. I'll discuss the problems we found along
the way and the use cases OpenSSL's support for post-quantum cryptography
unlocks for us.
To Be Confirmed
This talk will introduce the status of Post-Quantum Cryptography in China, including research, implementation and standardization.
The Tongsuo project, as OpenSSL's local fork in China, is also focusing on the migration to PQC.
This talk will also present the roadmap and development of PQC primitives in Tongsuo.
In this talk, I will discuss my OpenSSL contributions. My first contribution involves a potentially vulnerable code pattern that is the root cause of CVE-2022-37454, a buffer overflow vulnerability in the "official" SHA-3 implementation (Mouha and Celi, CT-RSA 2023). Jaroslav Lobačevski of GitHub Security Lab found the same pattern in OpenSSL, specifically in its HKDF implementation. (HKDF, which stands for HMAC-based Key Derivation Function, is used in TLS 1.3, the protocol that keeps your browser connection secure.) My second contribution is related to OpenSSL issue #13210 ("Incorrect usage of the HMAC APIs"), which discusses an attack when HMAC_Update() is invoked after HMAC_Final() (Benmocha et al., SAC 2020). It surprised me that the attack is no longer possible since OpenSSL 3.2.0 due to a change in the HMAC API, and I proposed adding a regression test to document the new API behavior.
The OpenSSL library implements the Certificate Management Protocol CMP [RFC 9483 etc.]
and Bouncy Castle contains support for CMP and CRMF messages [RFCs 4210 and 4211].
At Siemens both libraries interoperate by making use of CMP for managing product certificates.
Among others, this is used by the CoreShield S2L2 Linux platform, which is also applied in the Civil Infrastructure Platform.
In this talk I'm going to give technical insight which features of the two libraries we use with CMP
and how they interoperate in which OSS components in end entities, registration authorities (RAs), and CAs.
Their interaction via CMP provides secure and flexible enrollment, update, and revocation of X.509 certificates,
both at the device level and for services and applications running on various platforms.
Currently support for PQC (ML-DSA, SLH-DSA, optionally ML-KEM) and remote attestation is being added.
Learning OpenSSL can be intimidating, especially for beginners navigating cryptic commands and complex workflows. This talk introduces an interactive learning platform I have developed that uses simulated terminals, visual diagrams, quizzes, and hands-on labs to teach OpenSSL fundamentals in a more accessible and engaging way. Beyond the beginner experience, I will also share technical lessons learned from real-world deployments, including setting up TAXII servers with FIPS 140 compliance, handling OpenSSL limitations around subject string customization, and automating CRL updates where OpenSSL provides no built-in support. This session blends practical tools with deep technical insights to help teams confidently work with cryptographic systems.
To Be Confirmed
Should governments pay for the maintenance of open source software? If so, how should they do it — and how much is enough?
This talk will present the findings of a forthcoming feasibility study conducted by OpenForum Europe, together with Fraunhofer ISI and Professor Thomas Streinz of the European University Institute, on the potential design and impact of an EU Sovereign Tech Fund. The study provides a concrete economic and legal foundation for a structured European investment mechanism in open source software — one that could strengthen cybersecurity, reduce systemic risk, and advance digital sovereignty.
Beyond the technical findings, the presentation will reflect on the policy process itself: what it means to work with governments on digital infrastructure questions, and how the framing of open source as infrastructure is gaining traction in European policymaking. Drawing on OFE’s experience across institutions and Member States, this talk will offer insight into both the substance and the politics of public investment in open digital infrastructure.
Dive into the critical process of threat modeling for OpenSSL-based systems in this interactive 45-minute workshop. Through real-world scenarios, we'll explore how diverse threat models uncover distinct vulnerabilities and attack vectors. We'll analyze 2-3 specific OpenSSL use cases, such as HTTPS configurations or PKI systems, applying relevant techniques like STRIDE-LM or LINDDUN.
Designed for collaborative learning, participants will be given a case study and will work in small groups to identify threats, vulnerabilities, and potential mitigations. Facilitated discussions will provide constructive feedback, highlighting effective strategies. By the end, attendees will have a tangible understanding of building effective threat models, enhancing their ability to proactively secure OpenSSL deployments.
This lightning talk introduces the basics of email forensics for complete beginners. It will cover key parts of an email that can reveal valuable information and present some user-friendly tools to help analyze them.
Cryptography is the foundation of digital security. It is embedded across virtually every system and application. However, it can be of different forms: secure, insecure, vulnerable, compliant, non-compliant, current, outdated, and more. Today, there is a pervasive lack of visibility and control over cryptographic objects. Compliance requirements, quantum threat and the forthcoming post-quantum migration have further exposed these gaps.
To mitigate these risks, organizations must first establish comprehensive visibility, beginning with the capability to discover and inventory cryptographic objects across the entire ecosystem. Next, they must evaluate and assess the risk of these objects considering cryptographic vulnerabilities, compliance mandates, and the organization’s risk tolerance. Finally, they must define mitigation strategies and initiate remediation efforts. Migrating cryptographic objects is a highly complex process, as they are almost always hardcoded into systems, making replacement both difficult and resource intensive.
In this session, we will explore two main components of Cryptographic Lifecycle Management: Cryptographic Discovery and Cryptographic Agility. For Cryptographic Discovery, we will examine what is required to discover and inventory cryptographic objects. For Cryptographic Agility, we will outline the core solution principles and highlight the latest efforts from Standards Bodies driving PQC Algorithms adoption like NIST, ENISA, NCSC, and others.
PQConnect is a post-quantum end-to-end tunneling protocol that
automatically protects all packets between clients that have installed
PQConnect and servers that have installed and configured PQConnect.
Like VPNs, PQConnect does not require any changes to higher-level
protocols and application software. PQConnect adds cryptographic
protection to unencrypted applications, works in concert with existing
pre-quantum applications to add post-quantum protection, and adds a
second application-independent layer of defense to any applications
that have begun to incorporate application-specific post-quantum
protection.
Unlike VPNs, PQConnect automatically creates end-to-end tunnels to any
number of servers using automatic peer discovery, with no need for the
client administrator to configure per-server information. Each server
carries out a client-independent configuration step to publish an
announcement that the server’s name accepts PQConnect connections. Any
PQConnect client connecting to that name efficiently finds this
announcement, automatically establishes a post-quantum point-to-point
IP tunnel to the server, and routes traffic for that name through that
tunnel.
People writing crypto and security software rely on standards set by standards bodies in order to create secure and interoperable implementations. But what happens when the principal standards body involved has been severely dysfunctional for years, captured by large business interests and professional meeting-goers paid to churn out more and more documents, often of dubious or even no value? This talk looks at one such standards body, and why and how it went off the rails.
LUKS2 is a de-facto standard disk encryption format for Linux today.
It is managed by the cryptsetup tool and split into the kernel (dm-crypt) and userspace parts.
The talk briefly describes the LUKS2 maintainer's journey over the last several years and cryptsetup requirements for the cryptography backend, where OpenSSL is the default library choice.
I will address both historical experiences as well as current takes at the security (product) certification for novel cryptographic constructions, with an outlook for the Security Target and Protection Profile establishment (for the novel algorithms) within the Common Criteria (and indirectly thus also EUCC) environment. The talk will also summarize suggestions for future steps in the path of such certifications.
Heimdal has an ASN.1 compiler and library that can fully encode/decode a certificate including all its extensions in one codec invocation. It does this by leveraging the RFC 5912 object sets, parameters, and constraints on PKIX. Showcasing Heimdal's ASN.1 tooling might help OpenSSL develop its own (or borrow Heimdal's) to a) be able to use ASN.1 modules as-is rather than having to rely on error-prone manual translation to OpenSSL's macros for defining ASN.1 types, and b) to get automatic use of RFC 5911 and 5912 to simplify the use of ASN.1 in OpenSSL.
For example, Heimdal can decode a certificate and print it as JSON, with all the certificate's extensions fully decoded, in two invocations: one to decode a DER-encoded certificate, and one to encode the result as JSON.
Open-source software lays down a very transparent community of
developers and products. While allowing public access to the sensitive
behind-the-scenes operation of a program sounds risky, open-source
software actually has the potential to be even more secure than a
program with hidden code.
This talk explores the evolution of open-source from a security
perspective and reviews how it has evolved over time. It emphasises
on bursting the myths around cybersecurity and open-source
software.
Quantum Key Distribution (QKD) offers a promising leap forward in secure communications, leveraging quantum mechanics to establish unconditionally secure keys. However, real-world deployment of QKD requires interoperability with traditional cryptographic libraries and key management systems.
In this session, we outline our experiences in how to use OpenSSL and Bouncy Castle with QKD systems using standardized protocols, and how to securely manage and distribute those keys using the KMIP (Key Management Interoperability Protocol) standard.
We show practical integration steps and how organizations can use familiar tools—OpenSSL and Bouncy Castle—to bridge today’s cryptographic infrastructure with the quantum-secure future, both with PQC algorithms and QKD hardware solutions.
By using AES-XTS mode as a vehicle, this talk teaches SIMD/vectorization optimization practices, some of the principles used to make those optimizations, and why these optimizations work on modern hardware. It does this with code samples throughout, which bounce back-and-forth between the actual assembly found in the XTS implementation and a by-the-book implementation so the two can be compared. Finally, the talk finishes with a few optimizations that are not strictly vectorization-related, but are nonetheless fun and interesting,
A panel discussion with members of the Business and Technical Advisory Committees. We will be discussing the future of the OpenSSL Library and the community that maintains it.
The rise of GenAI will see an ever-increasing amount of data being gathered from citizens, both for the training of machine learning models and in the processing of PII (Personally Identifiable Information). Unfortunately, the data gathering and processing infrastructures that we have often pay little attention to the privacy of the data gathered. This presentation outlines both the theoretical and practical aspects of building a privacy-aware data gathering and processing infrastructure using Fully Homomorphic Encryption (FHE), Zero Knowledge Proofs (ZKPs) and MPC (Multi-party Computation).
TLS 1.3 and QUIC lack native mechanisms for refreshing cryptographic keys or certificates during long-lived sessions which creates challenges for applications like always-on VPNs, IoT, or real-time streaming. This talk explores the security risks of long-lived sessions and reviews recent IETF work (Extended Key Update and Certificate Update) that aim to address these gaps. We’ll compare with TLS 1.2 renegotiation, highlight how other protocols like Wireguard, SSH and IKEv2 approach key rotation, and examine existing workarounds used in practice. The session is targeted at implementers, protocol designers, and security practitioners interested in evolving TLS and QUIC for modern use cases.
Dencrypt provides end-to-end encrypted communications for its customers and is part of a research project to showcase a video call encrypted with QKD keys. This talk presents how Dencrypt envisions this to be achieved with OpenSSL.
Open Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto ResearchOpen Quantum Safe, OQS & Post-Quantum Crypto Research
As post-quantum cryptography (PQC) continues to evolve, ensuring a smooth and adaptable transition for end users, developers, and system administrators remains a top priority. Our presentation and live demo will showcase the establishment of a PQC TLS 1.3 connection using OpenSSL-based servers and Firefox-based clients, leveraging both key exchange and authentication. These research results are part of a Horizon Europe project named QUBIP.
In QUBIP, we aim to enable the PQC transition for three major practical exercises: quantum-secure IoT-based digital manufacturing, quantum-secure internet browsing, and quantum-secure software network environments for telco operators. Our talk is focused on quantum-secure internet browsing.
We will conclude the session by describing the broader methodology behind these efforts and how shallow loadable modules can empower users, system administrators, developers, and cryptographers alike to achieve greater flexibility and security in a post-quantum world.
Keywords: PQC, Provider, PKCS#11
In this talk we will provide an overview of the challenges related to Post-Quantum cryptography and its migration from vulnerable cryptographic primitives. The objective of the talk will be to, at the same time, help raise and calm the panic about Post-Quantum Cryptography, and the critical role OpenSSL will play in ensuring proper development, use and widespread adoption of this new cryptographic schemes, associated to the release of the 3.5.0 version
In this talk, we will provide an overview of how OpenSSL is utilized in various components of our current car series. Collaborating with our business partners, we developed an internal OpenSSL provider that supports ed25519ph with our custom algorithm identifier (OID). We will share our experiences, detailing our approach and the challenges we overcame in the process.
To Be Confirmed
With the finalization of the initial three NIST standards for PQC, together with supporting standards from the IETF and X9, it has become possible to produce holistic implementations supporting the new PQC algorithms in Bouncy Castle APIs. Holistic in this case, means that in addition to supporting the algorithms themselves, it is now possible to meet the other requirements, such as support in CMS/SMIME, Time Stamping, or PGP protocol. Things which are really what make an algorithm "useful" as they do not require developers to work directly with the algorithms themselves and implicitly allow for a level of agility in code design. Of course the consideration of things like Time Stamping, immediately calls to question what do we do with the Time Stamps that we have? It turns out there are also, already, standards for supporting that use case as well. This talk will look at how the BC APIs have adapted to the new PQC algorithms, what we have done to improve "usefulness" while still allowing for, we hope, peaceful migration from the past, and what performance issues we have seen around this migration so far as well as what we have tried to do in order to help our user community take some of these things into account.
When encryption is everyone's job, it is no one's responsibility.
Who's in charge of encryption in DevOps? A simple question but rather challenging to implement. Tools are there, but lacking the understanding of 'why' largely contributes to this challenge. This presentation aims to bring a level of clarity to garner corporate buy-in. FedRAMP can be leveraged as a transformative tool in getting this accomplished.
The Postfix MTA supports email SMTP over TLS both as server (inbound) and client (outbound).
Postfix makes extensive use of the OpenSSL TLS API, out of approximately 166k lines of code, around 12k LOC are TLS-related. Postfix.
Multiple security models are available as either default or per-destination options:
- cleartext ("none"),
- opportunistic TLS ("may"),
- unauthenticated mandatory TLS ("encrypt")
- Pinned key/cert digests ("fingerprint")
- opportunistic DANE TLS ("dane")
- mandatory DANE TLS ("dane-only")
- mandatory PKIX TLS ("secure")
Advanced features include:
* Explicit initialisation with a non-default configuration file and/or application name
* Cross-process connection reuse
* Cross-process external session cache (primarily for clients)
* Ticket-based session resumption for servers, with regular session ticket encryption key rollover
* Per destination trust anchors,
* Multi-valued hostname checks,
* SNI-based key pair selection,
The DANE support in OpenSSL originated as code in Postfix, as part of which the X.509 certificate chain verification code was substantially cleaned up and extended. Other minor changes also originated in Postfix over the years.
As governments and regulators push for stronger digital security and AI accountability, the question is no longer if software developers will face legal risk—but when.
This session explores the emerging legal frameworks and liability theories placing developers—especially those working with cryptography, AI, and open-source tools—closer to the legal line. Whether maintaining encryption libraries, integrating LLMs, or building secure-by-design infrastructure, developers may soon find themselves navigating new legal duties, including under the EU AI Act, U.S. product liability laws, and global cybersecurity frameworks.
With real-world examples and forward-looking analysis, this talk unpacks the evolving risk landscape—and what organizations can do now to support and shield their developers.
In a recent poll, OpenSSL Communities members were asked what technical features should be prioritized for upcoming OpenSSL releases. The results of the poll ranked constant-time BIGNUM as the second-most requested feature. This contrarian talk discusses the challenges of designing and implementing a truly constant-time arbitrary-precision integer arithmetic software library, why the cryptographer's mantra "just make it constant time" is a pipe dream, and radical alternative approaches that eschew this intrinsic limitation.
What's the relationship status between open source projects and Post-Quantum Cryptography? It's complicated—but let me explain.
As Post Quantum Cryptography Alliance(PQCA)'s Vice Chair(TAC), OpenSSL TAC representative and founding member of NgKore, I'll give you the insider's guide to the entire PQC open source ecosystem. We'll explore how different open source projects & communities such as Linux Foundation's Post-Quantum Cryptography Alliance(PQCA) are developing PQC algorithms, CBOM(Cryptography Bill of Materials) and how they are handling PQC integration across different protocols & architectures. Some approaches are brilliant, others are... let's call them "creative".
You'll discover which projects depend on OpenSSL for their PQC journey versus those building their own solutions, how community strategies differ from PQCA initiatives to Linux distributions, and what industry organizations are actually doing (spoiler: it varies wildly). I will also examine how these implementations align with NIST standards and IETF drafts—or spectacularly don't.
By the end, you'll have a comprehensive map of PQC advancements across the open source landscape & Post Quantum Cryptography Alliance and practical insights for your own migration planning. Plus, you'll understand why the beautiful chaos of cryptographic migration is both terrifying and hilarious.
Quantum computing poses an imminent threat to today's cryptographic protocols, requiring urgent migration to post-quantum cryptography. Most projects include common protocols like TLS, mTLS, QUIC, SSH, OAuth, IPSec and many more in their security implementation. This session demonstrates practical implementation of these protocols and approaches to migrating them using OpenSSL's post-quantum capabilities (ML-KEM for key generation and ML-DSA for signatures).
The presentation introduces a prototype framework that implements security protocols with both classical and post-quantum algorithms, enabling developers to understand protocol mechanics, migration challenges, and hybrid approaches. The framework uses OpenSSL and open source libraries such as LibOQS, OQS Provider, and StrongSwan to showcase real-world PQC integration.
The session explores the working of these migrations with existing open source projects, demonstrating real-world PQC integration patterns. Attendees will gain hands-on experience with PQC implementation and leave with actionable guidance for migration projects.
This is a talk about wolfSSL's efforts to create compatibility layers for various cryptography libraries in order to swap in wolfSSL's FIPS 140-3 certified implementations. People familiar with wolfSSL's OpenSSL compatibility layer will be familiar with this concept.
Stephen has been implementing the Encrypted Client Hello (ECH) mechanism being developed in the IETF TLS working group and attempting to get code for that upstreamed into the library. The first part of that (HPKE) landed in late 2022 after an extended PR discussion. Remaining ECH functionality is even more complex and affects many parts of the TLS code and is in the process of being upstreamed into a feature branch. The talk will review some of the many reasons why attempting this turns out to be challenging, but will also argue that the project would be wise to strive to decrease the difficulty of (some but not all) activities like this.
With the rise of large language models (LLMs) and inference platforms, privacy concerns have intensified regarding how user prompts and contextual data are handled. Although TLS provides secure communication channels, plaintext inference data is still exposed to multiple layers of model-serving infrastructure before it reaches the model, including logging layers, proxies, and orchestration frameworks.
In this talk, we propose and demonstrate a practical framework that extends OpenSSL beyond transport encryption to enable model-side confidential inference. Input data is encrypted at the client using OpenSSL’s AES encryption suite and transmitted through standard protocols. Decryption occurs only within the model process, inside trusted memory space. We integrate this with the Model Context Protocol (MCP), a lightweight protocol increasingly used for orchestrating model input/output streams in modern LLM inference engines.
The result is a secure, auditable, and privacy-preserving pipeline where prompts remain encrypted until the moment the model begins inference. We’ll showcase working code examples using OpenSSL, compare performance trade-offs, and explore integration patterns for LLM stacks, including Llama.cpp, and/or vLLM.
This design opens new frontiers for OpenSSL, enabling cryptographic protection not just in web services, but inside the AI inference layer itself.
Cryptographic implementations demand both correctness and security but how do you optimize an algorithm like AES-CFB128 for modern CPUs? This case study explores the evolution of OpenSSL’s AES-CFB128 implementation, from a sequential AES-NI baseline to a high-performance VAES-optimized version (openssl#26902).
We’ll deep dive into:
- SIMD and compiler optimization techniques,
- performance measurement and characterization,
- tooling and debugging challenges,
- security considerations,
- lessons learned as an external contributor
Migration to post-quantum cryptography is a significant task fo IT community, however, for some stakeholders and developers the upcoming schemes seem cumbersome. We present an educational board game which shows players the process of developing and standardizing quantum-safe cryptographic schemes.
To Be Confirmed
The rapid advancements in quantum computing pose an existential threat to widely adopted classical cryptographic algorithms such as RSA and ECC. While a large-scale quantum computer has not yet materialized, the security of today's encrypted communications is already at risk due to the "harvest now, decrypt later" paradigm: adversaries can collect encrypted data now and decrypt it once quantum capabilities emerge.
To mitigate this looming threat, the cryptographic community has been actively developing and standardizing post-quantum cryptographic (PQC) algorithms. Among the most prominent are Kyber (for key encapsulation) and Dilithium (for digital signatures), both selected by NIST as part of its PQC standardization process.
This talk will explore the integration of PQC using the OpenSSL ecosystem, highlighting current support, best practices, and common pitfalls. We will walk through how to use Kyber (ML-KEM) and Dilithium (ML-DSA) in OpenSSL 3.5 and discuss implications for key exchange, TLS, and digital signatures.
Finally, we’ll present Qgram, a secure messaging system developed to showcase real-world usage of post-quantum cryptography. Qgram leverages Kyber and Dilithium to deliver end-to-end encrypted communication resilient to quantum attacks, demonstrating the feasibility and performance of PQC in latency-sensitive applications.
Key takeaways:
- Why RSA and ECC are vulnerable in a quantum world
- Understanding the harvest-now-decrypt-later risk
- How to use OpenSSL with Kyber and Dilithium today
- Lessons learned from integrating PQC into a production-grade messaging system
With the help of readily available OpenSSL call-back functions, it is possible to accurately measure the CPU-time spent in the various stages of a TLS v1.3 session establishment (ClientHello, ServerHello, CertificateVertify, etc). Accurate timings for the computation of the related crypto algorithms used during those stages can then be extracted. While standalone and/or synthetic performance measurements of crypto algorithms are broadly available, the presented approach thanks to in-situ measurements not only characterizes the actual algorithm implementation as used in OpenSSL, but also takes required collateral performance penalties for the use of the algorithms in the TLS v1.3 protocol into account (e.g., memory allocations, data copying, algorithm loading, merging hybrid secrets, etc.). This presentation provides an overview on the measurement techniques and shows detailed measured results with focus on various combinations of ML-KEM and ML-DSA which were introduced in OpenSSL v3.5.
The OpenSSL framework offers 3rd party provider developers the opportunity to build highly portable and agile implementations. In this talk we review the journey SafeLogic took in building an entropy provider that recently received the SP-800-90-B ESV From NIST.
The European Union post quantum roadmap argues for the transition to PQC with the Store Now, Decrypt Later threat. They also argue for the security of the critical infrastructure. The PQC debate centers around the SNDL threat model, which may shadow the debate on the critical identification infrastructure.
The authenticity of the identities stored on EID cards and biometric passports depends on digital signatures. A validity period of ten years of the cards and passports brings us to 2035 when we should already be quantum safe. The non-repudiation of the signatures is an essential security objective for the identification. A single forged signature could put in jeopardy the entire digital identification infrastructure.
The EU CRA, for example, mandates the developers to commit to the maintenance of products. That typically requires software upgrades to be issued to the products, and the upgrades to be digitally signed. The PQC Transition requires the backend to be upgraded, and potentially the agile crypto solutions implemented in the products. That mandates a rethink of the life-cycle models of the products, and of the development and production processes.
The talk will explore the PQC transition from the critical identification infrastructure point of view, tracing it to the EU E-Sign Workshop in 1999 and the evolution of the use of digital signatures in the public and private sector identification infrastructures. The presentation shall be solution centric despite the once in a lifetime frightening opportunity.
Post-quantum cryptographic (PQC) algorithms such as ML-KEM and ML-DSA are becoming essential components for securing embedded systems in a quantum-resilient future. However, their integration into resource-constrained environments presents significant challenges—particularly in achieving both formal assurance and side-channel resistance. In this talk, we highlight the limitations of existing software implementations of PQC for embedded devices, focusing on common vulnerabilities such as timing leakage, memory access patterns, and data-dependent branching. We discuss the challenges in formally verifying correctness and side-channel resistance for PQC software, especially when adopting masking or constant-time countermeasures. Furthermore, we examine how these protected implementations can be integrated into existing protocols such as TLS using libraries like OpenSSL, where maintaining modularity and performance without sacrificing security becomes nontrivial. Our insights are based on hands-on experience with verifying and benchmarking protected PQC implementations on ARM Cortex-M devices. The talk concludes with recommendations for combining formal methods, lightweight countermeasures, and pre-silicon validation techniques to support trustworthy deployment of PQC software in embedded security stacks.
The Linux on IBM Z (s390x) platform provides hardware-backed keys. These so called protected keys hide the clear keys from the Application and even the Operating System, while the platform provides instructions to do standard cryptographic operations with this key material.
The talk gives a brief introduction to this Hardware feature and why it was not possible to exploit it in OpenSSL prior to version 3.5.0. The main part of the talk will focus on how the new EVP_SKEY API changes the game and gives an insight to the implementation. As a summary, the talk gives some arguments why using hardware-backed keys (via the EVP_SKEY API) increases the security of applications.
As the OpenSSL community continues to evolve and foster greater collaboration, understanding real-world performance and industry feedback is of increasing significance. In this session, we share our experience upgrading our firewall portfolio from OpenSSL 1.1.1 through 3.4, with a focus on TLS 1.2 and 1.3. We aim to contribute actionable feedback and engage in a broader discussion around tuning, optimization, and future improvements based on our observations and performance data.
OSSL Conference Pre-approved Topic alignment: Who Knows What Goes Into Products? Supply Chain Security Challenges
Abstract:
Many cyberattacks have exploited vulnerabilities and weaknesses in software and within software supply chains; an issue that spans both proprietary and open-source software which impacts both private sector and government enterprises.
This session will cover the software acquisition guide which provides a prescriptive method to assess hidden security challenges and poor practices in supply chain ecosystem.
This talk will cover past mistakes and success from shipping major OpenSSL upgrades in Ubuntu and Chainguard from the perspective of an engineering manager and an individual contributor. Covering past transitions such as 1.1.0 to 1.1.1 back in Ubuntu 18.04 Bionic, to considering upcoming deprecations and feature parity and interoperability.
Recent years have seen several landmark results in the formal verification of high-performance cryptographic libraries, leading to verified crypto code being adopted by mainstream projects like Chrome, Firefox, and Linux, including encryption algorithms and elliptic curves from the HACL* library.
More recently, formally verified post-quantum cryptography developed by Cryspen within the libcrux library has been integrated into Firefox, OpenSSH, and Signal. Furthermore, as classical Diffie-Hellman based protocol frameworks like TLS and Signal begin to incorporate post-quantum cryptography, they require new formal analysis for both their design and implementation. In this talk, I will survey approaches towards the formal verification of production-ready cryptographic software by drawing from several successful projects and discussing their limitations. I will then describe my long-term vision of how formal verification of modern high-performance multi-platform libraries like OpenSSL can go hand-in-hand with open-source software development, and how this process can provide higher assurance as well as support the long-term maintainability of cryptographic software.
This talk, "SSL Stack Sovereignty: Why Your Cloud Provider's TLS Is a Legal Liability," reveals how cloud providers' SSL/TLS implementations create hidden legal risks for your organization. Despite all major clouds advertising FIPS 140-2/3 compliance, a 6-month study found 100% have fallback mechanisms to vulnerable crypto, directly violating their own claims. This isn't merely a technical flaw; it's a legal time bomb, as recent FTC rulings make YOU directly liable for your provider's crypto misrepresentations.
We will expose the "Schrödinger's FIPS" paradox, where providers like AWS and Azure claim FIPS compliance while using non-compliant algorithms, such as AWS ELB falling back to AES-128 under stress or Azure’s TLS 1.3 using OpenSSL code banned in EU government systems. Case studies highlight severe penalties, including $8M FTC fines for blindly trusting cloud TLS and $2.3M fines for organizations using "compliant" services, compounded by 83% of cloud contracts shifting crypto liability to the user.
Attendees will learn to forensically audit their cloud crypto configurations to expose these deceptive practices. We will provide court-admissible validation methods using open-source tools and demonstrate how to generate legally defensible audit trails. This session offers actionable strategies to protect your organization from significant legal and financial exposure by empowering you to verify, enforce, and contractually secure your cloud crypto.
OpenSSL is everywhere, powering secure communication in the systems we rely on
daily. However, that reach also makes it a prime target for attackers. In this
session, we will walk through how to use threat modeling, with a focus on
STRIDE and attack trees, to uncover weak spots and vulnerabilities in OpenSSL-based systems before
attackers do. We will look at where vulnerabilities tend to creep in, from
unsafe defaults and risky configurations to flawed assumptions in system
design. I will also share what a solid incident response plan looks like when
cryptographic components are involved, especially under standards like FIPS
140-3. Whether you are writing code, securing infrastructure, or preparing for
the next zero-day, you will leave with practical strategies to reduce risk and
respond more effectively when something breaks.
Today’s “RAG” (Retrieval‑Augmented Generation) systems rely on vector databases, yet the vectors they store are fully invertible: with only the embedding you can reconstruct the original confidential text. In a live demo we will show how a few dozen lines of Python extract embeddings from an off‑the‑shelf ChromaDB instance and recreate sensitive source documents—then contrast this with an impossible inversion attack against the same workload running on CyborgDB, the first end‑to‑end‑encrypted vector database.
The talk opens by quantifying the privacy gap that stalls 46 % of AI pilots in regulated industries. We dissect the attack surface of plaintext embeddings, illustrate a successful extraction + inversion attack, and measure how often real‑world deployments leak data. We then deep‑dive into the cryptographic design of CyborgDB (which uses OpenSSL). Benchmarks show only 15 % latency overhead versus plaintext search and 7× throughput uplift on GPU accelerators, making encrypted retrieval practical for production workloads. Audience members will leave with working open‑source code, Docker images, and clear architectural patterns for plugging confidential vector search into any OpenSSL‑based stack.
.NET supports Linux since 2016. To avoid shipping cryptography code, .NET relies on cryptographic libraries present on the target platform (Schannel and CAPI on Windows, OpenSSL on Linux, etc.).
We will dive deeper into some noteworthy challenges we faced when we extended our originally Windows-only source code to work with OpenSSL on Linux. From multi-targeting multiple OpenSSL versions to loading multiple versions into the same process, we want to cover the most interesting challenges and differences.
The National Cyber and Information Security Agency of the Czech Republic has confirmed that “harvest now, decrypt later” attacks are no longer a theoretical threat—they are already a reality. In this talk, I will demonstrate how to protect sensitive data by integrating post-quantum key exchange into the TLS protocol. This hybrid approach, combining classical and quantum-resistant algorithms, is already supported by major web browsers and several TLS libraries. Attendees will learn how to adopt these mechanisms today to provide practical, forward-compatible security in the face of emerging quantum threats.
To Be Confirmed