# Crypto++ 8.9: what the C++ cryptography library gives you, and what it does not > Crypto++ is a free C++ class library of cryptographic schemes covering block ciphers, hashes, public-key algorithms and a filter/pipeline interface. It is a good fit for C++ codebases that need a self-contained crypto library, and a poor fit for anyone who needs a currently FIPS-validated module or a build system the project does not ship. **weidai11/cryptopp** — free C++ class library of cryptographic schemes - Repository: https://github.com/weidai11/cryptopp - Website: https://cryptopp.com - Stars: 5,511 · Forks: 1,679 - Language: C++ - License: NOASSERTION - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/weidai11-cryptopp ## What Crypto++ 8.9 solves, and who it is written for Crypto++ is a free C++ class library of cryptographic schemes. The README lists the algorithm families it contains: authenticated encryption (GCM, CCM, EAX, ChaCha20Poly1305, XChaCha20Poly1305), stream ciphers (ChaCha, Salsa20, XSalsa20, XChaCha20, Sosemanuk, Panama), AES and the AES candidates, a long list of other block ciphers including ARIA, Camellia, SM4, Threefish and Triple-DES, block cipher modes from ECB through XTS, MACs including HMAC, CMAC, GMAC, Poly1305 and SipHash, hash functions from SHA-1 through SHA-3 and SHAKE, public-key algorithms (RSA, DSA, ElGamal, Rabin-Williams, ESIGN), key agreement (DH, MQV, HMQV, FHMQV), and elliptic curve cryptography (ECDSA, ed25519, ECIES, ECDH, x25519). The README also lists a set of insecure or obsolescent algorithms retained for backwards compatibility and historical value, among them MD2, MD4, MD5, DES, RC2 and ARC4. The intended user is a C++ developer who wants those primitives in one library rather than assembling them from several sources. The README notes that the library was originally written by Wei Dai and is now maintained by several team members and the community, and that you may use it for any purpose without paying anyone, with the details left to License.txt. The last push to the repository was on 2026-08-05, and the most recent tagged release listed is CRYPTOPP_8_9_0 from 2023-10-01. The presence of the obsolescent algorithms is a design decision worth naming. Keeping MD5, DES and ARC4 in the same library as SHA-3 and ChaCha20 means the library serves code that has to interoperate with old formats, but it also means a developer can reach for a broken primitive without any warning from the type system. Crypto++ gives you the menu; it does not stop you ordering from the wrong part of it. ## The filter and pipeline interface, and what thread safety actually means here The README describes "a high level interface for most of the above, using a filter/pipeline metaphor". That is the mechanism most application code touches: data flows through a chain of filter objects, and the library handles the buffering between stages. The pipeline metaphor is why a typical Crypto++ program reads as a sequence of attached filters rather than a set of function calls. Two usage notes in the README govern how objects behave, and both matter more than they look. The first is ownership: if a constructor for A takes a pointer to an object B (except primitive types such as int and char), then A owns B and will delete B when A is destroyed. If the constructor takes a reference instead, the caller retains ownership and must not destroy B until A no longer needs it. This is a raw-pointer ownership convention, not a smart-pointer one, and getting it backwards produces either a double free or a dangling reference. The second is thread safety. The README states that Crypto++ is thread safe at the class level, which means you can use it in a multithreaded application, but you must provide synchronization when multiple threads access a common Crypto++ object. The distinction is easy to misread. Class-level thread safety means two threads can each hold their own AES object without interference. It does not mean a shared filter chain is safe to feed from two threads. If your design shares a cipher object across a thread pool, the synchronization is your responsibility, and the README says so plainly. Underneath that interface the library carries its own multi-precision integer and polynomial operations, finite field arithmetic over GF(p) and GF(2^n), and prime generation and verification. Those are not exposed as a separate product; they are the substrate the public-key code runs on. ## Installing Crypto++ and running a first encryption The README points at http://www.cryptopp.com for the most up to date build instructions and porting notes, and the repository ships Install.txt alongside the source. On Unix-like systems the top-level build entry point is the GNUmakefile, with GNUmakefile-cross present for cross-compilation. The README's own build path for that makefile is the one the repository documents. On Windows, the README gives the MSVC path: open cryptest.sln and build one of the projects. The README names them: the "cryptest Non-DLL-Import Configuration" builds the full static library along with a full test driver, the "cryptest DLL-Import Configuration" builds a static library containing only algorithms not in the DLL plus a test driver that uses both, cryptdll builds the DLL, and dlltest builds a sample application that only uses the DLL. For a new project the non-DLL-import static configuration is the one that matches the README's own warning about the DLL, discussed below. There is no CMakeLists.txt at the top level of the repository. The related searches include "cryptopp cmake", and the honest answer from the repository layout is that CMake is not the project's build system: the top-level entries are GNUmakefile, GNUmakefile-cross and the Visual Studio solution. If your project is CMake-based, you are writing the integration yourself or relying on something outside this repository. The README gives the include-order rule for the DLL path: to use the Crypto++ DLL in your application, include dll.h before including any other Crypto++ header files, and place the DLL in the right location. That rule only applies if you go the DLL route, which the README itself discourages. Once the library is built, the pipeline interface is what you write against. The README's own example is the test driver built from the same sources, so the first real thing to run is that driver rather than a hand-written snippet: it exercises the algorithms and the validation testing the README lists as a feature. ## The FIPS DLL is retired, and the README says so The strongest limitation is stated by the project itself. The README says the DLL used to provide FIPS validated cryptography, that the library was moved to the CMVP's Historical Validation List, that the library and the DLL are no longer considered validated, and that you should no longer use the DLL. It also notes that if you wish to use Crypto++ as a FIPS validated module you must use a pre-built DLL that has undergone the FIPS validation process instead of building your own, and then immediately tells you that DLL is historical. For anyone whose reason for picking Crypto++ was a FIPS claim, that path is closed. The static library is not a validated module either. If a compliance requirement is driving the choice, this is the point where Crypto++ stops being the right tool, and no amount of algorithm coverage changes that. A second limitation is the compiler matrix. The README lists supported compilers for this release as Visual Studio 2003 through 2022, GCC 3.3 through 13.1, Apple Clang 4.3 through 12.0, LLVM Clang 2.9 through 14.0, C++ Builder 2015, Intel C++ Compiler 9 through 16.0, Sun Studio 12u1 through 12.7, and IBM XL C/C++ 10.0 through 14.0. That is a wide historical range, but it is also a ceiling: newer compiler versions are not in the list for the 8.9 release, and the README directs you to the website for porting notes rather than promising support. A third is the release cadence visible in the release list. The tags run 8.7 in 2022-08, 8.8 in 2023-06 and 8.9 in 2023-10. Commits continued after that, with the last push on 2026-08-05, but the most recent tagged release is still 8.9 from 2023-10-01. If you track tags rather than the branch, you are working against a release that is older than the repository's activity. ## Crypto++ versus OpenSSL, and when the comparison decides OpenSSL is the obvious alternative and appears in the related searches as "cryptopp vs openssl". The difference in approach is visible from the interfaces. OpenSSL is a C library with an extensive command-line tool, a configuration file, and a provider and engine architecture; it is also the library that most system TLS stacks link against, which means it is usually already present on the machine. Crypto++ is a C++ class library with a filter/pipeline interface, no command-line tool of its own, and no TLS stack in the feature list the README gives. It is something you link into your program, not something you configure on the host. That difference decides most cases. If you need a TLS server or client, Crypto++ is not offering that; the README's feature list is primitives, not protocols. If you are writing C++ and want the primitives expressed as C++ objects with ownership and pipeline semantics, Crypto++ matches the language you are already in, and OpenSSL's C API means writing more glue. If your build already depends on OpenSSL for TLS, adding Crypto++ for a hash means shipping two crypto libraries, two sets of update cycles and two sets of advisories. Bouncy Castle is the other name in the related searches. It is the same idea as Crypto++ in a different ecosystem: a broad primitive library for a managed language rather than C++. If your application is C++, that difference is the whole argument. The related searches also mention cryptopp-modern, which the README does not describe. The repository here is weidai11/cryptopp, and nothing in the README, the top-level entries or the release list accounts for a separate project under that name. Treat it as a different codebase until you have read its own documentation. ## Licence, upgrade cost and what to check before you commit The repository's licence field is NOASSERTION, meaning the metadata does not map cleanly to a standard SPDX identifier. The README says you are welcome to use the library for any purpose without paying anyone, but adds "see License.txt for the fine print", and License.txt is a top-level file. The practical consequence is that you cannot rely on an SPDX label to clear this for your organisation; someone has to read License.txt and compare it against your distribution model. That is not legal advice, it is the step the repository's own metadata forces on you. Upgrade cost has two components here. The first is the build: with no CMake project in the repository, every consumer either uses GNUmakefile or the Visual Studio solution directly, or maintains its own integration. That integration is the thing that breaks, not the library. The second is the release cadence: with the newest tag at 8.9 from 2023-10-01 while commits continued to 2026-08-05, a team that pins to tags is testing a snapshot that predates years of branch activity, and a team that tracks master is testing unreleased code. Neither is free, and the README does not describe a middle option such as a maintenance branch. The compiler list compounds this. GCC support is listed through 13.1 and LLVM Clang through 14.0 for the 8.9 release. A team on a newer toolchain is outside the documented matrix and should expect to consult the porting notes the README points to rather than assume a clean build. ## Conclusion Adopt Crypto++ if you are writing C++ and want one library that covers AES, SHA-2, SHA-3, RSA, ECDSA, ed25519, x25519, PBKDF2, scrypt and HKDF without pulling in a C dependency or a package manager. Do not adopt it if your compliance path requires a currently FIPS-validated module: the README states the DLL was moved to the CMVP Historical Validation List and is no longer considered validated, and it says you should no longer use the DLL. Before writing code, verify three things in your own checkout: that your toolchain appears in the supported compiler list, that your build of choice is GNUmakefile or the cryptest.sln Visual Studio solution rather than a CMake project (the repository has no CMakeLists.txt at the top level), and that the licence text in License.txt matches how you intend to distribute the library. ## FAQ ### What is the Crypto++ library? It is a free C++ class library of cryptographic schemes, originally written by Wei Dai and now maintained by several team members and the community. The README lists block ciphers, stream ciphers, hash functions, MACs, public-key algorithms, key agreement schemes and elliptic curve cryptography, plus a high level filter/pipeline interface. ### How do I install Crypto++? The README points to http://www.cryptopp.com for the most up to date build instructions and porting notes, and the repository ships Install.txt. On Unix-like systems the top-level entry point is GNUmakefile; on Windows the README directs you to open cryptest.sln and build one of the listed projects. ### Is Crypto++ an alternative to OpenSSL? It overlaps on primitives but not on protocols. Crypto++ is a C++ class library with a filter/pipeline interface and no TLS stack in its feature list, while OpenSSL is a C library with a command-line tool that most system TLS stacks link against. The choice usually follows from whether you need TLS or just the primitives. ### Is Crypto++ a good C++ library to choose? It is one of the broadest single-package collections of primitives for C++, covering authenticated encryption, hashes, public-key algorithms and elliptic curve cryptography behind one filter/pipeline interface. The trade-offs are the FIPS DLL being retired, a compiler matrix that stops at GCC 13.1 and LLVM Clang 14.0 for the 8.9 release, and no CMake project in the repository. ## Sources - [Issues](https://github.com/weidai11/cryptopp/issues) - [Project website](https://cryptopp.com) - [README](https://github.com/weidai11/cryptopp/blob/master/README.md) - [Releases](https://github.com/weidai11/cryptopp/releases) - [weidai11/cryptopp on GitHub](https://github.com/weidai11/cryptopp) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/weidai11-cryptopp