Encryption Forks: The Most Famous Split Events in the History of Cryptography

2026/04/12 09:30:17

Encryption history is usually told through algorithms, standards, and breakthroughs in mathematics. But some of the most important turning points came from something much more practical: software forks. In cryptography, a fork is rarely just a programmer dispute or a routine engineering branch. It usually happens when trust is under pressure—after a security crisis, a governance failure, a licensing conflict, or the abrupt end of a major project. When that happens, the community has to decide which codebase deserves to protect real systems going forward.

By the end of this article, you will have a clear picture of the most famous fork events in encryption history, why each split happened, and which projects became the representative names of those transitions. The central stories include the OpenSSL fork family, the fall of TrueCrypt and the rise of VeraCrypt, the NaCl to libsodium shift, and the SSH lineage that produced OpenSSH. Along the way, it also helps to distinguish a true code fork from a standards-based successor such as GnuPG in the OpenPGP ecosystem.

Hook

What does the internet do when the software protecting websites, servers, and encrypted files can no longer be trusted in its current form?

In cryptography, the answer is often a fork and some of those forks changed the security stack of the modern world.

Overview

This article covers the most famous fork events in the history of encryption, including:

OpenSSL and the projects that split from it, especially LibreSSL, BoringSSL, and later AWS-LC
TrueCrypt’s shutdown and the emergence of VeraCrypt
NaCl’s evolution into the more deployable libsodium
the SSH to OSSH to OpenSSH lineage
why GnuPG belongs in the conversation even though it is not a direct code fork of PGP

Thesis

The history of encryption forks shows that cryptography evolves through governance and implementation choices just as much as through theory. The best-known fork events became famous because they answered a hard question: when the original path no longer inspires enough trust, what project should take its place?

Timeline-style diagram showing major encryption fork lineages: OpenSSL to LibreSSL, BoringSSL, and AWS-LC; TrueCrypt to VeraCrypt and CipherShed; NaCl to libsodium; OSSH/SSH to OpenSSH; and PGP to GnuPG.

The role of forks in encryption history

In most software categories, a fork is simply a change in direction. In encryption, it usually means something much more serious. A fork tends to appear when confidence in the original project starts to weaken, whether because of a security failure, maintenance problems, governance issues, or the growing sense that the software is no longer reliable enough for such a sensitive role.

That matters because encryption software sits at the center of digital trust. It helps secure network connections, protect stored files, manage keys, validate certificates, and verify integrity. In other words, even if the cryptography itself is mathematically sound, the implementation still has to be trustworthy. Weak code, poor maintenance, or a project that is too difficult to audit can create real security risks. When a fork happens in this space, it is often less about developer preference and more about deciding which project should continue protecting real systems.

The most important encryption forks usually happen for a few recurring reasons:

a major vulnerability exposes deeper problems in the original codebase
the project becomes too complex or too outdated to maintain safely
a company needs a specialized branch for its own infrastructure
a respected design needs a more practical and portable implementation

These patterns explain why some forks become defining moments in cryptography history rather than minor side projects.

Security crises and trust recovery

Some of the most famous fork events begin after a public security shock. When that happens, the fork becomes a way to restore confidence. A new team can simplify the code, remove risky legacy parts, apply stricter review practices, and present a clearer security philosophy.

That is one reason forks in encryption attract so much attention. They are often responses to a broken trust model. The community is no longer asking which version is more convenient. It is asking which version is safer to depend on.

Maintenance, governance, and code quality

Forks also matter because secure software depends on strong stewardship. A project can remain popular for years while quietly becoming harder to review, harder to modernize, and more fragile beneath the surface. In encryption, that is especially dangerous because security software has to stay understandable and auditable over time.

A fork can provide a practical reset by creating:

clearer governance
stricter development standards
better long-term maintainability
a codebase that is easier to audit

In that sense, a fork is not always fragmentation. Sometimes it is the only realistic way to restore discipline and trust.

Direct forks and successor projects

It is also important to be precise with the term fork. Not every major split in encryption history is a literal code fork. Some projects directly branch from an older source tree, while others are better described as successors that continue the same role or standard.

A simple way to understand the difference is:

Direct forks continue from the original codebase
Successor projects take over the same function without being direct code copies
Standards-based continuations build around the same open standard rather than the same code

This distinction keeps the history accurate. OpenSSL to LibreSSL is a direct fork. NaCl to libsodium is also a direct fork. PGP to GnuPG belongs in the same broader historical discussion, but it is better understood as a standards-based successor rather than a strict codebase split.

That is what makes forks so significant in encryption history. They are not just technical branches. They are moments when the security community re-evaluates trust and decides which projects are strong enough to carry forward.

OpenSSL and the fork family that reshaped internet encryption

No fork event in practical encryption is more famous than the one centered on OpenSSL. For years, OpenSSL was one of the most widely deployed cryptographic libraries on the internet. It sat underneath TLS on servers, clients, operating systems, and embedded platforms. That made it a foundational infrastructure. But its importance also exposed the cost of complexity. When trust in such a project weakens, the consequences are much larger than in a typical application stack.

LibreSSL: the cleanup and hardening fork

LibreSSL emerged as one of the most visible answers to the question of what a safer crypto library should look like after the OpenSSL crisis years. The project describes itself as a version of the TLS and crypto stack forked from OpenSSL in 2014, with goals including modernizing the codebase, improving security, and applying best-practice development processes. That wording captures why LibreSSL became historically important. It was not merely a rebrand. It was a deliberate attempt to make a major crypto library easier to understand, easier to audit, and less burdened by legacy code.

The representative value of LibreSSL is symbolic as well as technical. It stands for the idea that cryptographic trust depends on maintainability. A mathematically secure system is not enough if the implementation is cluttered, inconsistent, or too difficult to review. LibreSSL became famous because it translated that concern into a fork with a clear mission and a strong security culture behind it.

BoringSSL: the specialized fork for Google’s ecosystem

Google’s answer to the same broad problem was different. BoringSSL describes itself as a fork of OpenSSL designed to meet Google’s needs, and it explicitly says it is not intended for general use in the same way OpenSSL is. That distinction is central to its place in history. LibreSSL represented one path: simplify and improve for a broad security audience. BoringSSL represented another: build a fork optimized for a tightly controlled internal ecosystem where compatibility tradeoffs can be handled centrally.

That is why BoringSSL matters even though it is not pitched as a universal downstream library. It shows how cryptographic forks can be driven by deployment realities as much as by public trust repair. Large platforms sometimes need the freedom to make aggressive API or ABI decisions that a general-purpose upstream project cannot make safely. BoringSSL became one of the most important encryption forks precisely because it reflects the priorities of a major production environment rather than the needs of every third-party consumer.

AWS-LC: a later branch in the same family

AWS-LC extends this lineage further. AWS describes AWS-LC as a general-purpose cryptographic library maintained by its cryptography team and based on code from the Google BoringSSL project and the OpenSSL project. This places AWS-LC within the same historical fork family, even though it arrived later. It shows how a major cryptographic base can give rise to several descendants with different operating assumptions: one focused on cleanup and auditing, one tailored to Google’s needs, and one adapted for AWS and customer environments.

Taken together, OpenSSL, LibreSSL, BoringSSL, and AWS-LC form the most consequential fork cluster in modern encryption history. They are representative projects not only because they share ancestry, but because each one expresses a distinct answer to the same question: how should critical cryptographic infrastructure be maintained and evolved?

TrueCrypt and the search for a trustworthy successor

If the OpenSSL story is the biggest infrastructure fork event, the TrueCrypt story is the most famous end-user encryption split. TrueCrypt became one of the best-known disk encryption tools in the world because it offered practical encryption for containers, partitions, and full disks across multiple platforms. Then the project effectively ended. The official site still warns that using TrueCrypt is not secure because it may contain unfixed security issues and says development ended in May 2014. That sudden discontinuity transformed the project from a trusted tool into a historical rupture.

VeraCrypt: the dominant successor

The most important representative project to emerge from that rupture was VeraCrypt. VeraCrypt presents itself as free open-source disk encryption software for Windows, macOS, and Linux. More importantly, it became the practical continuation of the TrueCrypt lineage for most users. When people discuss the famous TrueCrypt fork event, VeraCrypt is the name they usually mean. It inherited the urgency of the original project’s user base: people still needed encrypted containers, full-disk protection, and a maintained path forward.

VeraCrypt’s significance comes from continuity as much as innovation. In encryption, continuity is not trivial. Users cannot easily abandon tools that protect sensitive files and systems. A successful successor has to preserve enough familiarity to support migration while also creating confidence that the project is alive and being cared for. VeraCrypt became historically important because it managed that transition better than the other contenders.

CipherShed and the broader fork moment

CipherShed also belongs in the historical record as a notable TrueCrypt fork, even though it never became as prominent in practice as VeraCrypt. Its importance is representational: it reminds us that when a major encryption project collapses, communities often explore more than one rescue path. But over time, one successor usually becomes the recognized standard bearer. In this case, that was VeraCrypt.

The TrueCrypt episode is one of the clearest examples of a fork driven by stewardship collapse. There was no clean, orderly transition. Trust in the original project evaporated almost overnight. The fork event mattered because users needed a credible replacement immediately, not as an abstract engineering exercise but as an operational necessity.

NaCl to libsodium: the fork that improved usability

Not every famous encryption fork is born from scandal or crisis. Some become famous because they solve the quieter but equally important problem of usability. NaCl, the Networking and Cryptography library, was highly influential for its opinionated, modern approach to crypto APIs. It encouraged safer defaults and cleaner abstractions. But it was not always the easiest thing for mainstream developers to package, deploy, or integrate broadly across environments.

libsodium’s own documentation explains why it became the representative successor. It describes itself as a portable, cross-compilable, installable, and packageable fork of NaCl, with a compatible but extended API to improve usability. That description is not marketing fluff. It pinpoints the exact reason libsodium became historically significant. It made strong cryptography easier to use correctly in production software.

That kind of fork matters because poor ergonomics can become a security problem. When cryptographic libraries are difficult to integrate or easy to misuse, teams make mistakes. libsodium’s importance lies in bridging the gap between strong cryptographic design and practical software engineering. It carried forward NaCl’s modern philosophy while making it more accessible to application developers and language ecosystems.

Among developer-facing cryptography projects, NaCl to libsodium is one of the most influential fork events ever. It may not have generated the same public attention as the end of TrueCrypt, but in terms of long-term effect on how secure applications are actually built, it belongs near the top of the list.

SSH, OSSH, and OpenSSH

OpenSSH is sometimes discussed separately because it is a secure communications suite rather than a general-purpose crypto library. But historically it absolutely belongs in any serious list of famous encryption forks. The OpenSSH project history states that the OpenBSD team decided to fork from the OSSH release and pursue rapid development using the same kind of security-auditing process that shaped OpenBSD itself. That makes OpenSSH a clear fork event, not just an unrelated implementation.

What happened next is what makes the lineage so important. OpenSSH did not remain a side branch. It became the dominant SSH implementation across Unix-like systems and one of the most trusted secure remote access tools in the world. In practice, that means the forked line became the default line for a huge portion of internet infrastructure. That is one of the clearest examples of a fork winning so decisively that many users stop thinking of it as a fork at all.

The representative projects here are the original SSH lineage, OSSH, and OpenSSH. The importance of the fork lies in how it turned secure shell access into a standard operational capability backed by a widely trusted open implementation. That is a major chapter in the history of encrypted communications.

PGP and GnuPG: historically central, but not a direct code fork

PGP and GnuPG are often included in lists of famous encryption forks, but the relationship needs to be described carefully. GnuPG says it is a complete and free implementation of the OpenPGP standard. That means it sits in the same broad ecosystem as PGP and became the free-software answer to the same category of encryption and signing needs. But it is better understood as a standards-based successor than as a direct source-code fork.

That distinction is worth preserving because the history is clearer when terms are used precisely. If the question is about the broader “fork-like” turning points of encryption history, PGP and GnuPG belong in the conversation. If the question is about literal codebase forks, they do not fit in the same category as OpenSSL to LibreSSL or NaCl to libsodium. Still, GnuPG remains one of the most important representative projects in encryption history because it carried the OpenPGP model forward in an open and widely adopted form.

Encryption forks in crypto

At first glance, encryption forks may seem like a niche topic from the history of security software rather than something directly connected to crypto. But the relationship is closer than it appears. The crypto industry depends on trust at every level, and that trust is not built on blockchain design alone. It also depends on the security of the software stack behind wallets, key handling, authentication systems, APIs, internal communications, and the broader infrastructure that keeps digital assets protected.

Crypto depends on trusted security software, not just blockchain protocols.
Forks happen when trust weakens because of security issues, poor maintenance, or governance problems.
OpenSSL forks show how critical cryptographic infrastructure can split when the original project no longer feels sufficient.
TrueCrypt to VeraCrypt shows the need for a credible successor when an encryption tool loses trust.
NaCl to libsodium shows that easier-to-use cryptography can improve real-world security.
Main takeaway: crypto security depends on code quality, auditability, maintenance, and long-term stewardship.

Conclusion

The most famous fork events in the history of encryption are not famous because developers argued over code style. They are famous because they marked moments when the community had to rebuild trust in critical security software. The OpenSSL family produced LibreSSL, BoringSSL, and AWS-LC. The end of TrueCrypt elevated VeraCrypt as the leading successor. NaCl’s ideas reached wider production use through libsodium. The SSH lineage gave rise to OpenSSH, which became the standard secure shell implementation on much of the internet. And while GnuPG is not a direct fork of PGP, it remains one of the most important successor projects in the broader history of encryption.

OpenSSL, LibreSSL, BoringSSL, AWS-LC, TrueCrypt, VeraCrypt, CipherShed, NaCl, libsodium, SSH, OSSH, OpenSSH, PGP, and GnuPG. Together, they show that cryptography’s history is as much about stewardship and implementation as it is about theory.

Call to Action

Looking for more crypto education and practical blockchain insights? Browse the latest articles on KuCoin Learn and explore the full KuCoin platform for more.

FAQs

What is an encryption fork?

An encryption fork is a split from an existing cryptographic software project into a separately maintained codebase with its own development direction.

What is the most famous encryption fork?

The OpenSSL fork family is usually the most important by practical impact because it affected core internet security infrastructure and produced major descendants such as LibreSSL and BoringSSL.

Is VeraCrypt a fork of TrueCrypt?

VeraCrypt is the best-known successor in the TrueCrypt lineage and became the dominant maintained continuation after TrueCrypt development ended in 2014.

Is libsodium a fork of NaCl?

Yes. libsodium explicitly describes itself as a fork of NaCl with a compatible but extended API.

Was OpenSSH really a fork?

Yes. OpenSSH’s official project history says the OpenBSD team forked from the OSSH release.

Is GnuPG a fork of PGP?

Not in the strict codebase sense. GnuPG is better described as a free implementation of the OpenPGP standard.

Why do forks matter in cryptography?

They matter because they often determine which implementations users trust for secure communications, key handling, encrypted storage, and application security.

Which representative projects should I remember?

The key names are OpenSSL, LibreSSL, BoringSSL, AWS-LC, TrueCrypt, VeraCrypt, NaCl, libsodium, SSH, OSSH, OpenSSH, and GnuPG as a standards-based successor case.

Disclaimer: The information provided on this page may originate from third-party sources and does not necessarily represent the views or opinions of KuCoin. This content is intended solely for general informational purposes and should not be considered as financial, investment, or professional advice. KuCoin does not guarantee the accuracy, completeness, or reliability of the information, and is not responsible for any errors, omissions, or outcomes resulting from its use. Investing in digital assets carries inherent risks. Please carefully evaluate your risk tolerance and financial situation before making any investment decisions. For further details, please consult our Terms of Use and Risk Disclosure