Jeremy Allison helped create Samba, wrote some of its early cryptographic code, and came away with a rule he thinks every programmer should follow. “Never write your own cryptography,” he says. “The only exceptions to this, you know who you are.” Today, as a Distinguished Engineer at CIQ, he works on the other side of that rule, making sure the standard cryptographic libraries Linux depends on, including the new post-quantum algorithms, hold up under FIPS 140-3 scrutiny.

At CIQ, Jeremy leads the work toward FIPS 140-3 validation and Common Criteria evaluation for Rocky Linux from CIQ Pro (RLC Pro) and other CIQ products. The work brings together cryptographic frameworks, testing strategies, software engineering, and detailed standards requirements.

“Working at CIQ is the most interesting challenge I’ve had for a very long time,” he says.

A career built on open source

Jeremy is best known as one of the co-creators of the Samba project. Samba enables file and print interoperability between Windows and Linux and UNIX systems, bridging platforms that were not originally designed to work together.

That work also provided Jeremy’s introduction to cryptography. He wrote some of Samba’s early cryptographic code with help from Bruce Schneier’s book Practical Cryptography. He later created transport-level encryption for a custom SMB1 and POSIX protocol variant.

By Jeremy’s own assessment, the implementation “wasn’t very good, or very secure.” But it demonstrated the need for encrypted SMB traffic and helped inspire Microsoft to implement transport encryption properly in SMB3.

Samba soon moved from custom encryption code to the standard cryptographic libraries available on Linux. Jeremy’s work today focuses in part on ensuring that those foundational libraries satisfy exacting compliance requirements.

The work behind cryptographic compliance

Supporting a cryptographic algorithm and delivering a compliant implementation are two very different accomplishments.

“It requires an insane amount of detailed programming and test work,” Jeremy explains. “The cryptography packages shipped on Rocky are close to FIPS compliance, but when the lab starts looking through them, you’d be surprised how many little changes are required to bring them completely into FIPS standardization.”

Those changes can involve entropy source selection, the secure zeroization of intermediate values, test conformance, and key generation testing.

One of Jeremy’s most challenging projects at CIQ involved preparing the ML-KEM and ML-DSA implementations in Network Security Services, or NSS, for FIPS 140-3 validation. These algorithms are designed to protect systems against attacks from both conventional and future quantum computers.

Part of the NSS implementation had originally been written in Rust and then transpiled into C. Although the generated code was functional, it was not ready for FIPS validation. Generated functions created copies of intermediate values on the stack, and those values needed to be securely erased before the functions returned.

Addressing the problem required AI-assisted hand-edits and careful reviews throughout the generated code. The challenge did not end with the first successful revision.

“Then the package gets updated, the Rust-to-C code is regenerated, and all the work has to be done again,” Jeremy says.

The repetitive nature of that process illustrates why cryptographic compliance is so demanding. The work does not stop once an algorithm functions correctly. Every implementation detail must continue to satisfy the standard each time the underlying software changes.

From post-quantum skepticism to urgency

Jeremy was initially skeptical that quantum computing would become a practical threat to current cryptographic systems. He was more concerned about the increasing complexity of protocols such as TLS and Kerberos, which can make correct, secure implementations extremely difficult.

He still considers that complexity a more immediate danger for many organizations. But two developments in 2026 changed his view of the longer-term risk.

In March, Google Quantum AI researchers published new estimates suggesting that breaking the elliptic curve cryptography used by cryptocurrencies and other systems could require approximately 20x fewer quantum resources than previously estimated. Google used a zero-knowledge proof so others could verify the result without receiving a roadmap for reproducing the attack.

“This got my attention,” Jeremy says. “If the result is theoretical, you don’t go to the expense of using a zero-knowledge proof.”

Then, in July, Anthropic reported that its Claude Mythos Preview model had helped researchers find improved attacks against HAWK, a candidate in NIST’s post-quantum signature competition, and against a reduced-round version of AES. The HAWK team withdrew the candidate the next day. The findings do not compromise production systems, but they demonstrate how AI can accelerate the discovery of weaknesses in the mathematics underlying cryptographic algorithms.

For Jeremy, the lesson extends beyond any single quantum threat or algorithm.

“This demonstrates the urgent need for agility in being able to transition to new cryptographic algorithms, both post-quantum and conventional, in an AI-assisted world,” he says.

Cryptographic migration is therefore not simply a matter of selecting today’s strongest algorithms. Organizations need systems and processes that allow them to replace algorithms as threats, standards, and knowledge evolve.

Applying the lessons of Samba

Jeremy’s experience with Samba shaped how he approaches that challenge.

“It drummed into me the need for test-driven development,” he says. “Interoperability with your own systems is easy. Interoperability with other systems is where the rubber meets the road.”

Samba began as an attempt to reimplement a proprietary protocol suite. Its success helped demonstrate the value of documented protocols and rigorous interoperability testing. Jeremy believes that work contributed to Microsoft opening the protocol and creating the interoperability tests developers now use for SMB3.

Cryptographic compliance presents a different engineering problem because the tests and expected outputs are already defined. The difficulty lies in passing those tests across increasingly complex configurations while also protecting against less visible weaknesses, including incomplete zeroization, leaked key material, and timing attacks.

In both cases, success depends on disciplined testing, careful implementation, and the ability to examine how software actually behaves.

Open source as a scientific method

CIQ publishes its FIPS compliance changes as open source, with separate patches and detailed explanations of what changed and why. The work is available through the CIQ Rocky Linux FIPS repositories, allowing other developers to inspect it, learn from it, and contribute improvements.

For Jeremy, sharing this work is a natural continuation of the principles that have guided his career.

“Open source runs like a shining thread through everything CIQ does,” he says. “It’s the scientific method applied to creating robust, reliable, and secure software.”

“The code changes needed for FIPS only make sense as open source, applied and contributed back to the open source projects we use to achieve FIPS certification,” Jeremy says.

He hopes CIQ’s contributions will help other organizations and developers undertake their own compliance and post-quantum initiatives.

“We all learn and inspire each other by sharing our code and ideas,” he says. “I hope we can help others gain the knowledge and experience to pursue their own certifications.”

Building the cryptographic foundation for what comes next

Jeremy’s work at CIQ brings together the defining themes of his career: difficult technical problems, rigorous testing, practical interoperability, and a commitment to developing essential technology in the open.

The immediate objective is concrete: help RLC Pro and other CIQ products meet demanding FIPS and Common Criteria requirements while preparing for the transition to post-quantum cryptography. The broader goal is to give the open source community code, documentation, and experience that others can use to strengthen their own systems.

That shared foundation will become increasingly important as quantum computing advances, AI accelerates cryptographic research, and organizations face pressure to adopt new algorithms without compromising security or compliance. The algorithms will continue to change, but the need for inspectable code, comprehensive testing, and open collaboration will remain.

At CIQ, that work gives the “shining thread” of Jeremy’s career a new direction: helping build the open, verifiable cryptographic foundation that Linux will need next.