For most of the year, the people who keep OpenSSL working are spread across a mailing list, a pull-request queue, and a dozen time zones that rarely overlap. The library they maintain is not: it is the code much of the internet links against to keep a message private between sender and reader. Twice a year, the distributed team has to become a room. In the last week of May, that room was in Brno.
This is a letter about that week — not a changelog, but a field note on what happens when the maintainers, advisory-committee members, and invited guests from across the cryptographic world spend five days deciding, in person, what the next decade of this work should look like. The fine-grained detail belongs on a mailing list, and it will get there. What follows is the part worth telling the wider world: what the week was for, who was there, and why the people behind the world's most widely used cryptographic library held their most important conversations of the year in Brno.
Why the room was in Brno.
First, a word on what gathered there. The OpenSSL Corporation is not the library — it is the company behind it. Working directly with the maintainers, it provides the support plans, FIPS 140 validation, post-quantum readiness, custom engineering and long-term support that let organisations depend on OpenSSL with confidence, and it stewards the project, its communities, and its mission. The library is the artifact; the Corporation is the expertise and the continuity behind it. That is what came to Brno for the week.
It was no accident. OpenSSL Corporation opened its main office in Brno in August 2025, and the choice of city was deliberate. Brno is a university town with a deep, unshowy engineering culture and an open-source community that treats free software as the default. The talent is here; so is the temperament.
Over the months since, that presence has grown roots. As of early this year the Corporation has signed cooperation agreements with both of the city's major informatics faculties: an SME partnership with the Faculty of Informatics at Masaryk University, running through Professor Vashek Matyáš's Centre for Research on Cryptography and Security (CRoCS), and a Bronze partnership with the Faculty of Information Technology at Brno University of Technology, running through Associate Professor Kamil Malinka's Security@FIT group. Two faculties, two universities, one cooperation — and a bet that the next generation of cryptographers is already in those buildings.
Brno is a city of students and open source. And I love it when open source has real impact on industry.
So the venue chose itself: not a neutral conference hotel, but the place the Corporation is actually putting down roots — beside the universities it works with, in the country quietly becoming the European home of this work.
The shape of the week.
Five days is a long time to hold a room of senior engineers, and the agenda earned every hour. It moved deliberately across the things that decide OpenSSL's next decade: how the work gets done, what languages and architectures it is written in, how releases are made trustworthy, and how the people around the project stay connected to it.
The room itself was the point. Alongside the OpenSSL Corporation engineering team — among them President Tim Hudson, co-author of the original SSLeay code that became OpenSSL, with Anton Arapov, Milan Brož, Tomáš Vávra, Jaroslav Řezník, Nicola Tuveri, Alexandr Nedvědický, Bob Beck and colleagues — were invited guests from across the field: Megan Woods and David Hook of the Legion of the Bouncy Castle, Mike Ounsworth, Professor Peter Gutmann, Shayne Jones of Cryptlib, and academic and industry partners including Billy Brumley (RIT), Nikolas Gauder (TU München), Jeff Johnson (Cisco) and Simo Sorce (Red Hat) — the people doing the long-term research and integration that keeps cryptography honest.
AI, in the open.
No serious engineering conversation in 2026 avoids the question of what AI is good for, and OpenSSL's was free of hype in either direction. The consensus was practical: AI tooling has become genuinely useful for the mechanical parts of the craft — generating tests, tracing control flow through unfamiliar code, drafting documentation, summarising long security threads, catching the corner case a tired human misses. The Bouncy Castle team reported clearing a long ticket backlog far faster than before, and a debugging hunt that had run for an afternoon collapsing into minutes.
They were equally clear about the limits. A model is reliable at code generation and mechanical refactoring, and much less reliable at reasoning, judgement, and documentation that has to be true rather than merely fluent. So the old discipline holds: a human reviews everything, the build-test-commit loop stays sacred, and provenance is never assumed. The decision that belongs in the wider world followed from it. OpenSSL is moving to require that contributors disclose when AI tools were used to generate code, and confirm that a human reviewed the result — a transparency standard, prepared with legal input across several jurisdictions, not a ban. The position is plain: AI is welcome on the bench; undisclosed, unreviewed code in a library the world depends on is not.
Disclosure over detection. Accountability over prohibition.
The project is not trying to police every keystroke. It is asking contributors to be honest about their tools and to stand behind their work — the same expectation a serious profession has always had of the people in it.
The long arc.
One strategic theme ran the length of the week: OpenSSL intends to give the applications that depend on it more freedom in how their cryptography is implemented, without ever risking the trustworthiness of that cryptography. The mechanism is the provider architecture introduced in OpenSSL 3.0 and carried into 4.0 — a clean boundary that lets the cryptographic backend be swapped without rewriting the application above it.
That boundary is what keeps the Rust conversation sane. The room was deliberate about not sending the message that OpenSSL is "rewriting everything in Rust" — it isn't. It is investing seriously in memory-safe, Rust-capable integrations, and in the communities building them, so an application could in time choose a C provider, a Rust provider, or a Java route and get the same trustworthy primitives underneath. Much of the discussion centred on a clean-room Rust design built for safety from the first line: no unsafe code, no heap allocation by default, portable across anything the Rust compiler targets, and shaped so a key is hard to misuse by accident. The agreed posture was unglamorous: deliver tested, working code first, and talk about it second.
Already shipping, still advancing
The library's post-quantum work — ML-KEM, ML-DSA and SLH-DSA, the three finalised FIPS standards — is in hand and live. The week's focus was the road past the first algorithms: the migration story, and what the next round demands of the architecture.
From engines to a native provider
Talking to HSMs, TPMs and smart cards now happens through a modern PKCS#11 provider rather than the long-deprecated engine API — keys that never leave the hardware, spoken to in OpenSSL's native architecture.
The through-line of all of it — Rust, providers, post-quantum, hardware — is patience. None of it ships on a Friday; it is work that only means something across years, which is exactly why it needs a room, a whiteboard, and five uninterrupted days to get the direction right.
Trust you can verify.
A cryptographic library is only as trustworthy as the path its releases take from the maintainers' hands to yours, and a great deal of the week went into that path. Building on the production code-signing environment the Corporation has stood up around hardware security modules, the team worked through what real integrity demands: keys held in hardware, rotated on a schedule, and — crucially — revocation rehearsed before it is needed, so that recovering from a compromised key is routine rather than a crisis.
One idea captured the project's temperament: deliberately publishing test artifacts signed by revoked keys, so anyone downstream can confirm their own verification rejects what it should. Trust is not asserted but demonstrated — and the most reassuring thing a security project can do is give you the means to check its homework.
The part of the modern world that does not glow until it fails is the part worth maintaining properly — for as long as the world depends on it.
The community in the room.
OpenSSL is not only its maintainers. It is the distributions that ship it, the businesses that build on it, the individuals who file the bug that saves everyone else, and the academics who pressure-test its assumptions. A good part of the week was about keeping all of them genuinely connected to the project, not just nominally attached to it.
The distribution community — the people who package OpenSSL for the Linux world and beyond — has met in person through the year, in Prague and Brussels, and the week reaffirmed that rhythm. So did the push to make contributing easier for people outside the core teams: clearer guidance, faster triage, and a shorter path between a newcomer's first pull request and a human who can help with it. And one idea was aimed squarely at the universities: a lightweight OpenSSL Academic Network, a low-friction way for institutions to affiliate, be discoverable, and connect students to real work — no governance entanglements, no financial strings.
Real problems, waiting to be picked up
- Brno, on the doorstep.CRoCS at Masaryk University and Security@FIT at Brno University of Technology — partners on applied cryptography, constant-time analysis, fuzzing and storage encryption.
- An international bench.Collaborators reaching from Brno to RIT and TU München — including a planned, pointed paper on the unrealistic threat models that too much academic security work still assumes.
- An honest deal for students.Not cheap labour — real supervisors, real problems, and the option to keep going if the work leads somewhere.
And the days did not end at the daily wrap. Each evening the room emptied into the city — a different table around Brno every night, from a brewery on Dominikánská to a square-side spot on náměstí Svobody — where the arguments softened into the kind of conversation that quietly builds the trust the work runs on. A week in one room is made as much over dinner as across the table.
The road to Prague.
Brno was where the work happened; Prague is where it goes public. In October the community gathers for the second OpenSSL Conference — 13 to 15 October 2026, with a tutorials day on the 12th — and several of the threads pulled in Brno will be tied off on stage. The conference takes its theme from Czech engineering history: the Křižík Effect, after František Křižík, who in 1881 struck an arc between two carbon rods in Prague and refused to let it sputter out — the moment electric light stopped being a novelty and became infrastructure.
The borrowing is apt, because cryptography now stands in that same gap. It has crossed from a specialist concern to civic infrastructure — payments, identity, transport, energy, public administration, the message you are reading right now. It is, as the organisers put it, the part of the modern world that does not glow until it fails. That this work has made the Czech Republic its home — a main office in Brno, partnerships with Czech universities, a conference in Prague — is a story Brno and the country can rightly claim a share of.
We would be honoured to share the room. The conversations that began in Brno deserve the widest audience in Prague — the engineers and academics who do this work, and the civic and national leaders for whom secure digital infrastructure is no longer a technical footnote but a matter of public trust. The arc was lit long ago; the work now is keeping it alight.
The room you can't get on a video call.
The OpenSSL maintainers, three days in Prague. The conversations that began in Brno carry to the conference hall — the engineers, the academics, and the people who depend on this work, in one room.
What stays with you.
By the last evening, what stayed was not any single decision. It was the room itself — the reminder that a piece of software most of the internet relies on is maintained by a finite number of people willing to fly to Brno and argue, carefully and in good humour, about how to keep it trustworthy for the next thirty years. You cannot replace that with a video call, and you certainly cannot replace it with a model. It needs people in a room who care about the work.
OpenSSL is in Brno because that matters. The week in May was one table inside a much longer relationship — with the city, with its universities, with the open-source world, and with the country that is becoming the home of this work. And the table is already booked again: the community meets in Prague in October, and the team reconvenes in December, straight after PKIC in Amsterdam. There will be more letters before then. This is the second.
With thanks to everyone who came to Brno — the engineering team, the advisory community, and the invited guests from across the cryptographic world — and to the Faculty of Informatics at Masaryk University and the Faculty of Information Technology at Brno University of Technology, our partners in this city.
Letters from Brno is an editorial series from OpenSSL Corporation on the work at the intersection of cryptography, open source, and the city of Brno.