Hubbry Logo
Comparison of cryptography librariesComparison of cryptography librariesMain
Open search
Comparison of cryptography libraries
Community hub
Comparison of cryptography libraries
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Comparison of cryptography libraries
Comparison of cryptography libraries
Comparison of cryptography libraries
View on Wikipedia
from Wikipedia

The tables below compare cryptography libraries that deal with cryptography algorithms and have application programming interface (API) function calls to each of the supported features.

Cryptography libraries

[edit]
Name of implementation Initiative Main implementation language Open-source software Software license Latest release
Botan Jack Lloyd C++ Yes Simplified BSD 3.8.1 (May 7, 2025; 6 months ago (2025-05-07)[1]) [±]
Bouncy Castle Legion of the Bouncy Castle Inc. Java, C# Yes MIT License
Java1.81 / June 4, 2025; 5 months ago (2025-06-04)[2]
Java LTSBC-LJA 2.73.7 / November 8, 2024; 12 months ago (2024-11-08)[3]
Java FIPSBC-FJA 2.0.0 / July 30, 2024; 15 months ago (2024-07-30)[4]
C#2.6.1 / May 22, 2025; 5 months ago (2025-05-22)[5]
C# FIPSBC-FNA 1.0.2 / March 11, 2024; 20 months ago (2024-03-11)[6]
BSAFE Dell, formerly RSA Security Java, C, Assembly No Proprietary Crypto-C Micro Edition: 4.1.5 (December 17, 2020; 4 years ago (2020-12-17)[7]) [±]


Micro Edition Suite: 5.0.3 (December 3, 2024; 11 months ago (2024-12-03)[8]) [±]
Crypto-J: 7.1 (July 30, 2025; 3 months ago (2025-07-30)[9]) [±]

6.3.1 (May 15, 2025; 6 months ago (2025-05-15)[10]) [±]

cryptlib Peter Gutmann C Yes Sleepycat License or commercial license 3.4.8 (April 30, 2025; 6 months ago (2025-04-30)[11]) [±]
Crypto++ The Crypto++ project C++ Yes Boost (all individual files are public domain) Jan 10, 2023 (8.9.0)
GnuTLS Nikos Mavrogiannopoulos, Simon Josefsson C Yes LGPL-2.1-or-later 3.8.10[12] Edit this on Wikidata 2025-07-09
Intel Cryptography Primitives Library Intel C, ASM Yes Apache 2.0 March 2025 (2025.1.0 / 1.1.0)
Java's default JCA/JCE providers Oracle Java Yes GNU GPL v2 and commercial license

25 LTS (September 16, 2025; 2 months ago (2025-09-16)[13]) [±]
21.0.5 LTS (October 15, 2024; 13 months ago (2024-10-15)[14]) [±]
17.0.13 LTS (October 15, 2024; 13 months ago (2024-10-15)[15]) [±]
11.0.25 LTS (October 15, 2024; 13 months ago (2024-10-15)[16]) [±]
8u431 LTS (October 15, 2024; 13 months ago (2024-10-15)[17]) [±]

LibreSSL OpenBSD Foundation C Yes Apache 1.0 4.2.1[18] Edit this on Wikidata 2025-10-31
Libgcrypt GnuPG community and g10code C Yes GNU LGPL v2.1+
stable1.11.2 / August 4, 2025; 3 months ago (2025-08-04)[19]
LTS1.8.11 / November 16, 2023; 2 years ago (2023-11-16)[20]


libsodium Frank Denis C Yes ISC Sep 13, 2023 (1.0.19)
Mbed TLS Arm Limited C Yes Apache 2.0 3.0.0 (July 7, 2021; 4 years ago (2021-07-07)[21]) [±]

2.27.0 (July 7, 2021; 4 years ago (2021-07-07)) [±]
2.16.11 (July 7, 2021; 4 years ago (2021-07-07)) [±]

NaCl Daniel J. Bernstein, Tanja Lange, Peter Schwabe C Yes Public domain February 21, 2011[22]
Nettle C Yes GNU GPL v2+ or GNU LGPL v3

3.10.2[23] Edit this on Wikidata 2025-06-26

Network Security Services (NSS) Mozilla C Yes MPL 2.0
Standard3.84 / October 12, 2022; 3 years ago (2022-10-12)[24]
Extended Support Release3.79.1 / August 18, 2022; 3 years ago (2022-08-18)[24]
OpenSSL The OpenSSL Project C Yes Apache 2.0 3.6.0[25] Edit this on Wikidata 2025-10-01
wolfCrypt wolfSSL, Inc. C Yes GNU GPL v3 or commercial license 5.8.2 (July 17, 2025; 4 months ago (2025-07-17)[26]) [±]

FIPS 140

[edit]

This table denotes, if a cryptography library provides the technical requisites for FIPS 140, and the status of their FIPS 140 certification (according to NIST's CMVP search,[27] modules in process list[28] and implementation under test list).[29]

Implementation FIPS 140-2 mode FIPS 140-2 validated FIPS 140-3 validated
Botan No No No
Bouncy Castle Yes Yes[30] Yes[31]
BSAFE Yes Yes[32][33] Yes[34]
cryptlib Yes No No
Crypto++ No No[a] No
GnuTLS No Yes[35][b] In process[36]
Intel Cryptography Primitives Library No [c] No [c] No [c]
Java's default JCA/JCE providers No No[37][d] No
Libgcrypt Yes Yes[38][e] In process[36]
libsodium No No No
Mbed TLS No No No
NaCl No No No
Nettle No No No
Network Security Services (NSS) Yes Yes[39][f] In process[36]
OpenSSL Yes Yes[40][g] Yes[41]
wolfCrypt Yes Yes[42] Yes[43]
  1. ^ Crypto++ received three FIPS 140 validations from 2003 through 2008. In 2016 NIST moved Crypto++ to the Historical Validation List.
  2. ^ While GnuTLS is not FIPS 140-2 validated by GnuTLS.org, validations exist for versions from Amazon Web Services Inc., Oracle Corporation, Red Hat Inc. and SUSE LLC.
  3. ^ a b c Intel Cryptography Primitives Library is not FIPS 140-3 validated but FIPS 140-3 compliant.
  4. ^ While none of default JDK JCA/JCE providers is FIPS 140-2 validated, there are other JCE/JCA third party providers which are FIPS 140-2 validated.
  5. ^ While Libgcrypt is not FIPS 140-2 validated by g10code, validations exist for versions from Amazon Web Services Inc., Canonical Ltd., Oracle Corporation, Red Hat Inc. and SUSE LLC.
  6. ^ While the Network Security Services (NSS) are not FIPS 140-2 validated by the Mozilla Foundation, validations exist for versions from Amazon Web Services Inc., Canonical Ltd., Cisco Systems Inc., Hewlett Packard Enterprise, Oracle Corporation, Red Hat Inc., SafeLogic Inc., SUSE LLC and Trend Micro Inc.
  7. ^ While OpenSSL is not FIPS 140-2 validated by OpenSSL.org, validations exist for versions from Amazon Web Services Inc., Aqua Security Software Ltd., Broadcom Inc., Canonical Ltd., Cisco Systems Inc., Cohesity Inc., ControlUp Technologies Inc., Crestron Electronics Inc., Dell Inc., Gallagher Group, Hewlett Packard Enterprise, IBM Corporation, ICU Medical Inc., Intelligent Waves, Ixia, KeyPair Consulting Inc., Koninklijke Philips N.V., Lenovo Group Limited, LG Electronics Inc., LogRhythm, McAfee LLC, Metaswitch Networks Ltd, NetBrain Technologies Inc., Nutanix Inc., Onclave Networks Inc., Oracle Corporation, REDCOM Laboratories Inc., Red Hat Inc., SafeLogic Inc., Super Micro Computer Inc., SUSE LLC, Tanium Inc., Trend Micro Inc., Unisys Corporation, Verizon, VMware Inc. and Wickr Inc.

Key operations

[edit]

Key operations include key generation algorithms, key exchange agreements, and public key cryptography standards.

Public key algorithms

[edit]
Further information: Public-key cryptography
Implementation RSA DSA ECDSA EdDSA Ed448 DH ECDH ECIES ElGamal NTRU
(IEEE P1363.1) 		DSS
Botan Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes
Bouncy Castle Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
BSAFE Yes Yes Yes No No Yes Yes Yes No No No
cryptlib Yes Yes Yes No No Yes Yes No Yes No Yes
Crypto++ Yes Yes Yes No No Yes Yes Yes Yes No Yes
GnuTLS Yes No No No No No No No No No No
Intel Cryptography Primitives Library Yes Yes Yes Yes No Yes Yes No No No Yes
Java's default JCA/JCE providers Yes Yes Yes Yes Yes Yes Yes No No No Yes
Libgcrypt Yes Yes Yes Yes Yes Yes Yes[a] No Yes No Yes
libsodium No No No Yes No No No No No No No
Mbed TLS Yes Yes Yes No No Yes Yes No No No No
Nettle Yes Yes No Yes No No No No No No No
OpenSSL Yes Yes Yes Yes Yes Yes Yes No No No No
wolfCrypt Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes
  1. ^ By using the lower level interface.

Elliptic-curve cryptography (ECC) support

[edit]
Further information: Elliptic-curve cryptography
Implementation NIST SECG ECC Brainpool Curve25519 Curve448 GOST R 34.10[44] SM2
Botan Yes Yes Yes Yes Yes Yes Yes
Bouncy Castle Yes Yes Yes Yes Yes Yes Yes
BSAFE Yes Yes No No No No No
cryptlib Yes Yes Yes No No No No
Crypto++ Yes Yes Yes Yes No No No
GnuTLS Yes No No No No No No
Intel Cryptography Primitives Library Yes No No Yes [a] No No Yes
Java's default JCA/JCE providers Yes Yes No Yes Yes No No
Libgcrypt Yes Yes Yes Yes Yes Yes Yes
libsodium Yes No No Yes Yes No No
Mbed TLS Yes Yes Yes Yes No No No
Nettle Yes Partial No Yes No No No
OpenSSL Yes Yes Yes Yes Yes Yes Yes
wolfCrypt Yes Yes Yes Yes Yes No Yes
  1. ^ Supported in Intel Cryptography Primitives Library multi-buffer API only (not supported in single-buffer API).

Public key cryptography standards

[edit]
Further information: PKCS
Implementation PKCS #1 PKCS #5,[45] PBKDF2 PKCS #8 PKCS #12 IEEE P1363 ASN.1
Botan Yes Yes Yes No Yes Yes
Bouncy Castle Yes Yes Yes Yes Yes Yes
BSAFE Crypto-J Yes Yes Yes Yes No Yes
cryptlib Yes Yes Yes Yes No Yes
Crypto++ Yes Yes Yes[a] No Yes Yes
GnuTLS
Intel Cryptography Primitives Library Yes No No No Yes No
Java's default JCA/JCE providers Yes Yes Yes Yes Yes Yes
Libgcrypt Yes Yes[b] Yes[b] Yes[b] Yes[b] Yes[b]
libsodium No No No No No No
Mbed TLS Yes No Yes Yes No Yes
Nettle Yes Yes No No No No
OpenSSL Yes Yes Yes Yes No Yes
wolfCrypt Yes Yes Yes Yes No Yes
  1. ^ The library offers X.509 and PKCS #8 encoding without PEM by default. For PEM encoding of public and private keys the PEM Pack is needed.
  2. ^ a b c d e These Public Key Cryptographic Standards (PKCS) are supported by accompanying libraries and tools, which are also part of the GnuPG framework, although not by the actual libgcrypt library.

Hash functions

[edit]

Comparison of supported cryptographic hash functions. Here hash functions are defined as taking an arbitrary length message and producing a fixed size output that is virtually impossible to use for recreating the original message.

Implementation MD5 SHA-1 SHA-2 SHA-3 RIPEMD-160 Tiger Whirlpool BLAKE2 GOST R 34.11-94[46]
(aka GOST 34.311-95) 		GOST R 34.11-2012
(Stribog)[47] 		SM3
Botan Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Bouncy Castle Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
BSAFE Crypto-J Yes Yes Yes Yes Yes No No No No No No
cryptlib Yes Yes Yes Yes Yes No Yes No No No No
Crypto++ Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes
GnuTLS
Intel Cryptography Primitives Library Yes Yes Yes Yes No No No No No No Yes
Java's default JCA/JCE providers Yes Yes Yes Yes No No No No No No No
Libgcrypt Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
libsodium No No Yes No No No No Yes No No No
Mbed TLS Yes Yes Yes Yes Yes No No No No No No
Nettle Yes Yes Yes Yes Yes No No No Yes No No
OpenSSL Yes Yes Yes Yes Yes Yes Yes Yes Yes No Yes
wolfCrypt Yes Yes Yes Yes Yes No No Yes No No Yes

MAC algorithms

[edit]

Comparison of implementations of message authentication code (MAC) algorithms. A MAC is a short piece of information used to authenticate a message—in other words, to confirm that the message came from the stated sender (its authenticity) and has not been changed in transit (its integrity).

Implementation HMAC-MD5 HMAC-SHA1 HMAC-SHA2 Poly1305 BLAKE2-MAC
Botan Yes Yes Yes Yes Yes
Bouncy Castle Yes Yes Yes Yes Yes
BSAFE Crypto-J Yes Yes Yes Yes No
cryptlib Yes Yes Yes Yes No
Crypto++ Yes Yes Yes Yes Yes
GnuTLS
Intel Cryptography Primitives Library Yes Yes Yes No No
Java's default JCA/JCE providers Yes Yes Yes No No
Libgcrypt Yes Yes Yes Yes Yes
libsodium No No Yes Yes Yes
Mbed TLS Yes Yes Yes No No
Nettle Yes Yes Yes Yes No
OpenSSL Yes Yes Yes Yes Yes
wolfCrypt Yes Yes Yes Yes Yes

Block ciphers

[edit]

Table compares implementations of block ciphers. Block ciphers are defined as being deterministic and operating on a set number of bits (termed a block) using a symmetric key. Each block cipher can be broken up into the possible key sizes and block cipher modes it can be run with.

Block cipher algorithms

[edit]
Further information: Block cipher
Implementation AES 3DES Camellia Blowfish Twofish IDEA CAST5 ARIA GOST 28147-89[48]
/ GOST R 34.12-2015
(Magma[49] & Kuznyechik[50]) 		SM4
Botan Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Bouncy Castle[51] Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
BSAFE Crypto-J Yes Yes No No No No No No No No
cryptlib[52] Yes Yes No Yes No Yes Yes No No No
Crypto++ Yes Yes Yes Yes Yes Yes Yes Yes Partial[a] Yes
GnuTLS Yes No Yes No No No No No No No
Intel Cryptography Primitives Library Yes Yes No No No No No No No Yes
Java's default JCA/JCE providers Yes Yes No Yes No No No No No No
Libgcrypt Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
libsodium Partial[b] No No No No No No No No No
Mbed TLS Yes Yes Yes Yes No No No No No No
Nettle Yes Yes Yes Yes No No No No No No
OpenSSL Yes Yes Yes Yes No Yes Yes Yes Yes Yes
wolfCrypt Yes Yes Yes No No Yes No Yes No Yes
  1. ^ Crypto++ only supports GOST 28147-89, but not GOST R 34.12-2015.
  2. ^ libsodium only supports AES-256, but not AES-128 or AES-192.

Cipher modes

[edit]
Further information: Block cipher mode of operation
Implementation ECB CBC OFB CFB CTR CCM GCM OCB XTS AES-Wrap Stream EAX
Botan No Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
Bouncy Castle Yes Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes
BSAFE Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes No
cryptlib Yes Yes Yes Yes Yes No Yes No No No No No
Crypto++ Yes Yes Yes Yes Yes Yes Yes No Yes No Yes Yes
GnuTLS
Intel Cryptography Primitives Library Yes Yes Yes Yes Yes Yes Yes No Yes No Yes No
Java's default JCA/JCE providers Yes Yes Yes Yes Yes No Yes No No Yes Yes No
Libgcrypt Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes
libsodium No No No No Yes No Yes No No No No No
Mbed TLS Yes Yes No Yes Yes Yes Yes No No No No No
Nettle Yes Yes No No Yes Yes Yes No No No No No
OpenSSL Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes Yes No
wolfCrypt Yes Yes Yes Yes Yes Yes Yes No Yes Yes Yes Yes

Stream ciphers

[edit]

The table below shows the support of various stream ciphers. Stream ciphers are defined as using plain text digits that are combined with a pseudorandom cipher digit stream. Stream ciphers are typically faster than block ciphers and may have lower hardware complexity, but may be more susceptible to attacks.

Implementation RC4 HC-256 Rabbit Salsa20 ChaCha SEAL Panama WAKE Grain VMPC ISAAC
Botan Yes No No Yes Yes No No No No No No
Bouncy Castle Yes Yes No Yes Yes No No No Yes Yes Yes
BSAFE Crypto-J Yes No No No Yes No No No No No No
cryptlib Yes No No No Yes No No No No No No
Crypto++ Yes Yes Yes Yes Yes Yes Yes Yes No No No
GnuTLS
Intel Cryptography Primitives Library No No No No No No No No No No No
Java's default JCA/JCE providers Yes No No No Yes No No No No No No
Libgcrypt Yes No No Yes Yes No No No No No No
libsodium No No No Yes Yes No No No No No No
Mbed TLS Yes No No No Yes No No No No No No
Nettle Yes No No Yes Yes No No No No No No
OpenSSL Yes No No No Yes No No No No No No
wolfCrypt Yes No No Yes Yes No No No No No No

Hardware-assisted support

[edit]

These tables compare the ability to use hardware enhanced cryptography. By using the assistance of specific hardware, the library can achieve greater speeds and/or improved security than otherwise.

Smart card, SIM, HSM protocol support

[edit]
Further information: Smart card, SIM card, and Hardware security module
Implementation PKCS #11 PC/SC CCID
Botan Yes No No
Bouncy Castle Yes[a] No No
BSAFE Yes[b] No No
cryptlib Yes No No
Crypto++ No No No
GnuTLS Yes No No
Intel Cryptography Primitives Library No No No
Java's default JCA/JCE providers Yes No[c] No[c]
Libgcrypt Yes[53] Yes[54] Yes[54]
libsodium No No No
Mbed TLS Yes[55] No No
OpenSSL Yes[55] No No
wolfCrypt Yes No No
  1. ^ In conjunction with the PKCS#11 provider, or through the implementation of operator interfaces providing access to basic operations.
  2. ^ When using BSAFE Crypto-J in native mode using BSAFE Crypto-C Micro Edition.
  3. ^ a b Support is available through javax.smartcardio package of JDK.

General purpose CPU, platform acceleration support

[edit]
Further information: CPU
Implementation AES-NI SSSE3, SSE4.1 AVX, AVX2 AVX-512 RDRAND VIA PadLock Intel QuickAssist ARMv7-A NEON ARMv8-A cryptography instructions Power ISA v2.03 (AltiVec[a]) Power ISA v2.07 (e.g., POWER8 and later[a])
Botan Yes Yes Yes Yes Yes No No Yes Yes Yes Yes
BSAFE Yes[b] Yes[b] Yes[b] No Yes[b] No No No Yes[b] No No
cryptlib Yes Yes Yes No Yes Yes No No No No No
Crypto++ Yes Yes Yes No Yes Yes[c] No Yes Yes Yes Yes
GnuTLS Yes No No No No Yes No No No No No
Intel Cryptography Primitives Library Yes Yes Yes Yes Yes No No No No No No
Java's default JCA/JCE providers Yes[d] Yes[d] Yes[d] Yes[d] Yes[d] No No No Yes[d] No Yes[d]
Libgcrypt[56] Yes Yes Yes Yes Yes Yes No Yes Yes No Yes
libsodium Yes Yes Yes No No No No No No No No
OpenSSL Yes Yes Yes Yes Yes[e] Yes No Yes Yes Yes Yes
wolfCrypt Yes Yes Yes No Yes No Yes[57] Yes Yes[58] No No
  1. ^ a b AltiVec includes POWER4 through POWER8 SIMD processing. POWER8 added in-core crypto, which provides accelerated AES, SHA and PMUL similar to ARMv8.1.
  2. ^ a b c d e When using RSA BSAFE Crypto-J in native mode using BSAFE Crypto-C Micro Edition
  3. ^ Crypto++ only provides access to the Padlock random number generator. Other functions, like AES acceleration, are not provided.
  4. ^ a b c d e f g When using the HotSpot JVM
  5. ^ OpenSSL RDRAND support is provided through the ENGINE interface. The RDRAND generator is not used by default.

Code size and code to comment ratio

[edit]
Implementation Source code size

(kSLOC = 1000 lines of source code)

Code to comment lines ratio
Botan 133[59] 4.55[59]
Bouncy Castle 1359[60] 5.26[60]
BSAFE Crypto-J 271[a] 1.3[a]
cryptlib 241 2.66
Crypto++ 115[61] 5.74[61]
GnuTLS 363[62] 7.30[62]
Java's default JCA/JCE providers
Libgcrypt 216[63] 6.27[63]
libsodium 44[64] 21.92[64]
Mbed TLS 105[65] 33.9[65]
Nettle 111[66] 4.08[66]
OpenSSL 472[67] 4.41[67]
wolfCrypt 39 5.69
  1. ^ a b Based on Crypto-J 6.2.5, excluding tests source. Generated using https://github.com/XAMPPRocky/tokei

Portability

[edit]
Implementation Supported operating system Thread safe
Botan Linux, Windows, macOS, Android, iOS, FreeBSD, NetBSD, OpenBSD, DragonflyBSD, Solaris, AIX, QNX, Haiku Yes
Bouncy Castle General Java API: J2ME, Java Runtime Environment 1.1+, Android. Java FIPS API: Java Runtime 1.5+, Android. C# API (General & FIPS): CLR 4.
BSAFE Crypto-J Solaris, Linux, Android, FreeBSD, AIX, 32 and 64-bit Windows, macOS (Darwin) Yes
cryptlib AMX, ARINC 653, BeOS, ChorusOS, CMSIS-RTOS/mbed-rtos, DOS, DOS32, eCOS, embOS, FreeRTOS/OpenRTOS, uItron, MQX, MVS, Nucleus, OS/2, Palm OS, QNX Neutrino, RTEMS, SMX, Tandem NonStop, Telit, ThreadX, uC/OS II, Unix (AIX, FreeBSD, HP-UX, Linux, macOS, Solaris, etc.), VDK, VM/CMS, VxWorks, Win16, Win32, Win64, WinCE/PocketPC/etc, XMK Yes
Crypto++ Unix (AIX, OpenBSD, Linux, MacOS, Solaris, etc.), Win32, Win64, Android, iOS, ARM Yes[a]
GnuTLS Runs on most Unix platforms and Windows[68] ?
Intel Cryptography Primitives Library Windows 10/11, Windows Server 2019/2022, Red Hat Enterprise Linux (RHEL) 8/9, SUSE Linux Enterprise Server (SLES) 15 SP4 / SP5 / SP6, Ubuntu 22.04 LTS / 24.04 LTS, Rocky Linux 9, Fedora 39 / 40, Debian 12 Yes
Libgcrypt All 32- and 64-bit Unix Systems (Linux, FreeBSD, NetBSD, macOS etc.), Win32, Win64, WinCE, and more Yes[69]
libsodium macOS, Linux, OpenBSD, NetBSD, FreeBSD, DragonflyBSD, Android, iOS, 32 and 64-bit Windows (Visual Studio, MinGW, C++ Builder), NativeClient, QNX, JavaScript, AIX, MINIX, Solaris Yes
Mbed TLS Win32/64, Unix Systems, embedded Linux, Micrium's μC/OS, FreeRTOS ?
OpenSSL Solaris, IRIX, HP-UX, MPE/iX, Tru64, Linux, Android, BSD (OpenBSD, NetBSD, FreeBSD, DragonflyBSD), NextSTEP, QNX, UnixWare, SCO, AIX, 32 and 64-bit Windows (Visual Studio, MinGW, UWIN, CygWin), UEFI, macOS (Darwin), iOS, HURD, VxWorks, uClinux, VMS, DJGPP (DOS), Haiku Yes
wolfCrypt Win32/64, Linux, macOS, Solaris, ThreadX, VxWorks, FreeBSD, NetBSD, OpenBSD, embedded Linux, Yocto Linux, OpenEmbedded, WinCE, Haiku, OpenWRT, iPhone (iOS), Android, Nintendo Wii and GameCube through DevKitPro, QNX, MontaVista, NonStop, TRON/ITRON/μITRON, Micrium's μC/OS, FreeRTOS, SafeRTOS, Freescale MQX, Nucleus, TinyOS, HP-UX, AIX, ARC MQX, TI-RTOS, uTasker, embOS, INtime, Mbed, uT-Kernel, RIOT, CMSIS-RTOS, FROSTED, Green Hills INTEGRITY, Keil RTX, TOPPERS, PetaLinux, Apache Mynewt, PikeOS, Deos, Azure Sphere OS, Zephyr Yes
  1. ^ Crypto++ is thread safe at the object level, i.e. there is no shared data among instances. If two different threads access the same object then the user is responsible for locking.

References

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Comparison of cryptography libraries

View on Grokipedia
from Grokipedia
A comparison of cryptography libraries evaluates software packages that provide implementations of cryptographic primitives, protocols, and tools for tasks such as encryption, hashing, digital signatures, and key derivation, enabling developers to select options based on factors like functionality, performance, security, and usability. These libraries vary in scope, with some offering broad support for standards like AES, RSA, and elliptic curve cryptography, while others focus on specific domains such as post-quantum algorithms or high-performance symmetric encryption. Comparisons typically consider criteria including the range of supported algorithms, programming language bindings, licensing models (e.g., open-source vs. proprietary), ease of integration, and documentation quality, as these influence suitability for applications ranging from web servers to embedded systems. Notable libraries include , a widely used C library underpinning much of the internet's TLS infrastructure but with a history of vulnerabilities, including 203 Common Vulnerabilities and Exposures (CVEs) reported from 2005 to 2022, many related to and implementation flaws. Bouncy Castle, a Java-focused library, supports extensive algorithms and is FIPS 140-validated, making it popular for enterprise applications, though it requires careful configuration to avoid misuse. wolfSSL (formerly CyaSSL) emphasizes lightweight, embeddable cryptography with FIPS certification and low resource usage, ideal for IoT devices. BoringSSL, a of OpenSSL maintained by , prioritizes security hardening and debloating, showing lower vulnerability densities in empirical analyses. Security assessments in comparisons often highlight vulnerability types, such as the 48.4% of issues in C/C++ libraries stemming from memory errors, underscoring the value of libraries in memory-safe languages like Rust's ring or Go's crypto package. Performance and compliance are also key differentiators; for example, libraries validated under NIST's program, like the OpenSSL FIPS Provider and wolfCrypt, ensure adherence to federal security standards, which is critical for and regulated industries. Emerging trends in comparisons address post-quantum readiness and side-channel resistance, with tools like Google's Tink scoring highly for ease of use and misuse resistance through high-level APIs that abstract low-level details. Overall, such evaluations help mitigate risks, as cryptographic misconfigurations contribute to many real-world breaches, emphasizing the need for audited, actively maintained libraries.

Overview and Libraries

Major Cryptography Libraries

Cryptography libraries provide essential implementations of cryptographic primitives and protocols, enabling secure communication, data protection, and authentication in software applications. These libraries vary in their design philosophies, supported languages, and adoption across industries, with open-source options dominating due to their transparency and community-driven development. Prominent libraries include those written in low-level languages like C and C++ for performance-critical applications, as well as higher-level bindings for languages such as Java and Python. OpenSSL, first released in 1998 as a fork of the SSLeay library, is one of the most widely used cryptography libraries, particularly for implementing TLS/SSL protocols in web servers and networking software. Maintained by the OpenSSL Software Foundation, it supports a broad range of algorithms and is integral to tools like and . A significant historical milestone was the vulnerability discovered in 2014, which exposed memory in TLS connections and led to widespread security audits, funding increases, and architectural improvements in subsequent versions. In the C++ ecosystem, Crypto++ has been available since 1995, offering extensive implementations of symmetric and asymmetric algorithms, hash functions, and public-key infrastructure components; its last release (8.9) was in October 2023, with no support as of November 2025, limiting its suitability for emerging standards despite prior use in embedded systems and high-performance applications. Developed by with community contributions, it emphasizes portability across platforms without external dependencies. Similarly, Botan, initiated in 2001, adopts a that allows selective inclusion of , targeting use cases in secure messaging and file encryption; it is maintained by the Randombit organization and integrates well with C++ standards. For Java and .NET environments, Bouncy Castle, launched in , provides comprehensive support for over 200 algorithms, including advanced features like key stores and CMS signed data, catering to enterprise applications and mobile development. It is actively maintained by the Legion of the Bouncy Castle organization and serves as a for Java's JCE provider. Other major libraries include (formerly CyaSSL), a lightweight C library with validation, optimized for embedded systems and IoT with low resource usage; BoringSSL, Google's fork of focused on security hardening and reduced ; mbedTLS (formerly PolarSSL), a portable C library for embedded and networked applications; and Google's Tink, a multi-language library emphasizing misuse-resistant high-level APIs for protocols like . Modern libraries prioritize usability and security by design, such as libsodium, released in 2013 as a portable fork of the NaCl (Networking and Cryptography library). Focused on simple, high-level APIs to reduce common misuse, it supports and is used in projects like VPN and Signal messaging app; maintenance is handled by the libsodium team with contributions from the community. In Python, the library (cryptography.io), introduced in 2013, offers bindings to and native implementations for primitives like AES and RSA, emphasizing secure defaults for web frameworks such as Django and Flask.

Comparison Methodology

The comparison of cryptography libraries utilizes standardized tables to evaluate key attributes, with support for algorithms denoted as "yes" for complete, production-ready implementations, "partial" for experimental or restricted features, and "no" for lack of support, as determined from each library's official and documentation. Performance metrics are selectively incorporated, such as throughput rates in megabytes per second (MB/s) for operations like AES-256-GCM on common hardware (e.g., processors), to highlight without overwhelming detail; these are normalized to avoid hardware-specific biases. For instance, a representative support table might appear as follows:
LibraryAES-256 SupportECC (P-256) SupportPost-Quantum KEM Support
OpenSSLYesYesYes
libsodiumYesNoNo
BotanYesYesYes
This format ensures clarity and enables quick cross-library assessment. Criteria selection prioritizes security (e.g., adherence to validated standards), completeness (breadth of supported primitives aligned with NIST and IETF recommendations), and usability (API intuitiveness and documentation quality) over raw speed, as cryptographic failures often arise from implementation flaws rather than performance deficits, and benchmarks can fluctuate with optimizations or platforms. This approach aligns with established evaluation frameworks that emphasize reliability in high-stakes environments like TLS deployments. Data is sourced exclusively from authoritative references, including official library documentation, the ECRYPT Benchmarking of Asymmetric and Symmetric Systems (eBACS) via its toolkit for symmetric primitive performance (last major release incorporating ongoing submissions as of 2023, with results applicable to 2025 evaluations), and NIST's Cryptographic Module Validation Program (CMVP) reports for certification status up to November 2025. Independent validations, such as those from peer-reviewed surveys, supplement these to verify claims. All comparisons reference the latest stable releases as of November 10, 2025—for example, OpenSSL 3.5 (LTS release from April 2025), Botan 3.10.0 (November 2025), and equivalent updates for libraries like libsodium and Bouncy Castle—while noting deprecations such as SHA-1, which NIST mandates phasing out by 2030 and which modern releases either disable or issue warnings against to mitigate collision vulnerabilities. Version-specific differences, like removed legacy support, are flagged to reflect evolving security postures.

Standards Compliance

FIPS 140 Validation

is a U.S. federal standard that defines security requirements for cryptographic modules used to protect sensitive information, administered by the National Institute of Standards and Technology (NIST) through the Cryptographic Module Validation Program (CMVP). The standard specifies four increasing levels of security, each building on the previous to address a range of applications and environments. , published in 2002, was the prior version, but it has been superseded by , published on March 22, 2019, with an effective date of September 22, 2019, and testing commencing on September 22, 2020; new validations are now under , while legacy certificates remain active until their sunset dates. The security levels under FIPS 140-3 are as follows:
LevelDescription
1Basic security requirements are specified for a cryptographic module. No specific physical security mechanisms are required beyond the basic requirement for production-grade equipment. No specific requirements for tamper evidence or resistance to physical attack.
2Requires, in addition to the Level 1 requirements, role-based authentication and physical security mechanisms that provide a basic level of tamper evidence and resistance to simple unauthorized physical access.
3Requires, in addition to the Level 2 requirements, identity-based authentication mechanisms, physical security mechanisms that provide a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module, and additional requirements for the entry and output of sensitive data.
4Provides the highest level of security defined in this standard. Requires, in addition to the Level 3 requirements, physical security mechanisms that have a very high probability of detecting and responding to unauthorized attempts at physical access, use, or modification of the cryptographic module. The physical security mechanisms must protect against environmental conditions or fluctuations outside of the normal operating ranges for the module.
Most software-based cryptography libraries achieve Level 1 validation, as higher levels typically apply to hardware modules with advanced physical protections. The certification process involves independent testing by NIST-accredited Cryptographic and Security Testing (CST) laboratories, which verify compliance with requirements across areas such as module specification, ports and interfaces, roles and services, and cryptographic . Vendors submit modules for validation, defining clear boundaries for the certified cryptographic components; upon successful testing, NIST and the Canadian Centre for Cyber Security issue a certificate, listing the module on the CMVP validated modules database for up to five years. Significant updates to a certified module, such as algorithm changes or version upgrades, require revalidation to maintain compliance. Examples of FIPS-validated cryptography libraries include the FIPS Provider (version 3.1.2), certified under at Level 1 (Certificate #4985, active until March 10, 2030), which supports approved algorithms like AES and RSA but requires updates for future NIST standards. Similarly, the Bouncy Castle FIPS API (BC-FJA, version 2.1.1 and later) holds Level 1 certification (Certificate #4943, active until January 16, 2027), providing a suite of Java-based implementations for FIPS-approved . wolfCrypt, the cryptographic engine of , is also validated at Level 1 (e.g., Certificate #5032 as of November 2025), emphasizing lightweight implementations suitable for embedded systems. Modules compliant with the former NSA Suite B (now transitioned to Commercial Algorithm Suite) algorithms, such as those using NIST P-256 elliptic curves, are often included in these validations when they meet FIPS criteria. FIPS 140 validation is mandatory for U.S. federal agencies handling information under the Federal Information Security Modernization Act (FISMA), enabling and use of compliant libraries while ensuring and security assurance. However, certifications apply only to specific module versions and approved algorithms; non-approved modes or curves, even if secure, are excluded, potentially limiting flexibility in implementations like certain beyond NIST P-256. Revalidation needs after updates can delay adoption of new features, such as emerging post-quantum algorithms not yet standardized in FIPS.

Common Criteria and Other Certifications

The (CC) is an (ISO/IEC 15408) for evaluating the security of IT products and systems, providing a framework for assurance through seven Evaluation Assurance Levels (EAL1 to EAL7), where higher levels involve more rigorous testing, design analysis, and to ensure protection against implementation flaws and intentional attacks. EAL1 offers basic , while EAL4+—a common target for cryptographic modules—includes semi-formal design verification and methodical testing of operational security, making it suitable for high-assurance environments in and . Unlike the U.S.-focused validation, CC emphasizes global mutual recognition up to EAL4 and provides higher levels for specialized needs, influencing library selection for regulated deployments like government or financial systems. These certifications highlight how CC evaluations verify not only algorithmic correctness but also secure coding practices, reducing risks from buffer overflows or timing leaks prevalent in crypto software. Other certifications complement CC for specific domains. For payment systems, PCI DSS requires strong cryptography per its v4.0.1 standard (mandatory since March 31, 2025), where libraries like those supporting AES-256 and SHA-256 enable compliance by facilitating encrypted cardholder data transmission, though libraries themselves are not directly certified—instead, systems using them undergo assessment. ISO 27001, an information security management standard, mandates rules for cryptography use (Annex A.8.24), and libraries such as Botan or support this by providing auditable implementations for and hashing, aiding organizational certification without library-specific seals. Libsodium, emphasizing simplicity and misuse resistance, relies on independent security audits rather than formal certifications like CC, confirming no critical vulnerabilities in its core primitives. Certification impacts include enhanced trust against flaws. By 2025, CC evaluations increasingly incorporate (PQC), with NIAP developing Protection Profiles for PQC algorithms like and to ensure libraries support quantum-resistant keys without weakening classical security. This evolution addresses "" threats, prioritizing libraries with PQC roadmaps for future-proof compliance.

Asymmetric Cryptography Support

Public Key Algorithms

Public key algorithms form the foundation of asymmetric cryptography in modern libraries, enabling secure , , and digital signatures without prior shared secrets. Major libraries vary in their implementation of classical algorithms like RSA, DSA, and Diffie-Hellman (DH), with support influenced by security standards, performance considerations, and deprecation trends toward quantum-resistant alternatives. Comprehensive libraries such as and Bouncy Castle provide full implementations, including key generation and schemes, while more minimalist ones like libsodium prioritize modern elliptic-curve variants for . RSA, introduced in 1977, remains a widely supported public key algorithm for and signing, relying on the difficulty of factoring large primes. involves selecting two large primes and computing the modulus, with recommended sizes of 2048 to 4096 bits to achieve at least 112 bits of security through 2030, per NIST guidelines. offers complete RSA support, including probabilistic via RSA_generate_key_ex and integration with like OAEP for and PSS for signing. Bouncy Castle provides extensive RSA functionality in , supporting OAEP and PSS schemes through classes like RSAEngine and RSASSAPSS, enabling hybrid use in protocols such as TLS for key transport. In contrast, libsodium does not support RSA, focusing instead on Curve25519-based primitives to avoid the computational overhead of large-integer arithmetic. DSA, a discrete logarithm-based signature algorithm standardized in FIPS 186, is now considered legacy. FIPS 186-5 (2023) removed DSA as an approved algorithm for new digital signature generation and , allowing only verification of existing signatures. Earlier guidance (SP 800-131A Rev. 1) disallowed generation of DSA keys smaller than 2048 bits after 2013, and SP 800-131A Rev. 2 approves generation only for large keys (2048 or 3072 bits) but recommends migration to elliptic-curve alternatives due to inefficiency and vulnerabilities. retains DSA support for , including with DSA_generate_parameters and signing via DSA_sign, though it warns of its obsolescence. Bouncy Castle similarly implements DSA through DSA classes, but documentation emphasizes migration away from it. Libsodium omits DSA entirely, aligning with its modern-crypto ethos. Diffie-Hellman enables secure by allowing parties to compute a over an insecure channel, based on the problem. Classical DH uses prime moduli of at least 2048 bits for security, while its elliptic-curve variant (ECDH) offers efficiency with smaller keys; libraries often bundle them for hybrid TLS handshakes. Key generation for DH traditionally uses probabilistic methods reliant on generators to select private exponents. provides robust DH support, including parameter generation with DH_generate_parameters and ephemeral key exchange via DH_compute_key, essential for TLS 1.3. Bouncy Castle supports DH through DHKeyGenerator and integrates it with protocols, including finite-field and elliptic-curve modes. Libsodium limits support to ECDH via X25519 (crypto_scalarmult), eschewing classical DH for its higher computational cost and quantum vulnerability. For signature algorithms like DSA and ECDSA used in related protocols, deterministic nonce generation per RFC 6979—deriving nonces from the private key and message—enhances security against faulty randomness; and Bouncy Castle implement this for compatible signatures, reducing risks in TLS deployments.
LibraryRSA Support (Key Gen, Encrypt/Sign, Padding)DSA Support (Legacy)DH/ECDH Support (Key Exchange)
OpenSSLFull (2048-4096 bits, OAEP/PSS)Yes (up to 3072 bits, verification only post-2023)Full DH + ECDH
LibsodiumNoneNoneECDH (X25519 only)
Bouncy CastleFull (OAEP/PSS schemes)Yes (verification only post-2023)DH + ECDH
wolfSSLFull (2048-4096 bits, OAEP/PSS)Yes (legacy, verification)Full DH + ECDH
BoringSSLFull (2048-4096 bits, OAEP/PSS)Yes (legacy, verification)Full DH + ECDH
ring (Rust)Full (no gen, encrypt/sign, OAEP/PSS)NoneECDH (various curves)
Go cryptoFull (2048+ bits, OAEP/PSS)Deprecated (verification)DH + ECDH
Elliptic-curve variants of these algorithms, such as ECDH, extend classical support in the subsequent subsection.

Elliptic-Curve Cryptography (ECC)

(ECC) provides asymmetric that leverage the algebraic structure of elliptic curves over finite fields to achieve high security with reduced computational overhead compared to traditional systems like RSA. In cryptography libraries, ECC is primarily implemented through algorithms such as the (ECDSA) for digital signatures and Elliptic Curve Diffie-Hellman (ECDH) for , enabling secure and session key derivation. These implementations support standardized curves that balance security, performance, and , with libraries varying in their curve selections to address specific use cases like general-purpose security or applications. FIPS 186-5 (2023) also approves variants like Ed25519 for signatures, supported in libraries such as libsodium and . A key advantage of ECC is its ability to deliver equivalent security levels with significantly smaller key sizes; for instance, a 256-bit ECC key offers approximately the same strength as a 3072-bit RSA key, both providing around 128 bits of security against known attacks. This results in 2-5 times faster operations in benchmarks across libraries, particularly for and verification on resource-constrained devices, due to fewer arithmetic operations required in point multiplications. Libraries like libsodium default to for ECDH and related primitives, prioritizing its high speed and resistance to certain implementation pitfalls, while supporting conversions to Ed25519 for signatures. Major libraries exhibit distinct ECC implementations tailored to standards and performance needs. supports NIST curves such as P-256 and for ECDSA and ECDH, along with Brainpool curves for enhanced security in European standards-compliant environments, ensuring broad compatibility in protocols like TLS. Bouncy Castle extends this with secp256k1, a Koblitz curve optimized for Bitcoin's ECDSA signatures, facilitating integration in and applications. To mitigate side-channel attacks, such as timing or , these libraries incorporate constant-time arithmetic in their ECC routines, avoiding data-dependent branches during scalar multiplications and point additions. As of 2025, libraries are increasingly adopting hybrid approaches that combine ECC with post-quantum algorithms to future-proof key exchanges. Botan, for example, integrates its optimized ECC library with FIPS 203 ML-KEM support, enabling hybrid ECDH-ML-KEM key exchanges in TLS 1.3 for immediate classical alongside quantum resistance. As of 2025, integrates post-quantum providers for hybrid key exchanges combining ECC with ML-KEM (FIPS 203). This shift reflects broader industry trends toward migrating ECC-based systems without disrupting existing deployments.

Symmetric Cryptography Support

Block Cipher Algorithms

Block cipher algorithms form a core component of symmetric cryptography in libraries, enabling the encryption of fixed-size data blocks typically using 128-bit blocks. The (AES), standardized by NIST in FIPS 197, is the most widely supported , based on the Rijndael algorithm selected in 2001 and available in key lengths of 128, 192, and 256 bits. All major libraries provide comprehensive AES support, including authenticated modes like AES-GCM for combined and integrity protection. For instance, leverages AES-NI hardware instructions for accelerated performance on compatible processors. Legacy block ciphers such as DES and (3DES) are included in most libraries for but are deprecated due to vulnerabilities and insufficient security margins; NIST withdrew recommendations for 3DES in SP 800-67 Revision 2 effective 2024. DES operates on 64-bit blocks with a 56-bit effective key, while 3DES applies DES thrice for enhanced strength, yet both are unsuitable for modern use. Additional algorithms like , a 128-bit with 128-, 192-, and 256-bit keys developed by NTT and Electric and standardized in ISO/IEC 18033-3, are supported in several libraries including , Bouncy Castle, and Crypto++. , a 128-bit with up to 256-bit keys from the AES competition finalists designed by et al., is available in Bouncy Castle, Crypto++, and Botan. Crypto++ extends support to , another 128-bit standardized by the Korean government.
LibraryAES (128/192/256)DES/3DESCamelliaTwofishARIAOptimizations
OpenSSLYesYesYesNoNoAES-NI
Bouncy CastleYesYesYesYesYesNone specified
Crypto++YesYesYesYesYesPortable implementations
libsodiumAES-256 onlyNoNoNoNoNone specified
BotanYesYesYesYesYesAES-NI
wolfSSLYesYesYesNoYesNone specified
Mbed TLSYesYesNoNoYesAES-NI
From a security perspective, AES-256 maintains 128-bit effective against quantum attacks via , which provides a quadratic speedup reducing brute-force key search from O(2k)O(2^k) to O(2k/2)O(2^{k/2}) operations, where kk is the key length. Implementations vary between table-driven approaches, which use precomputed lookup tables for speed but risk side-channel attacks like cache timing, and bit-sliced methods that process bits in parallel for better portability and resistance to such attacks, as employed in some Crypto++ and Botan configurations. These choices balance performance and , with like AES-NI preferred in production environments. Block ciphers are typically paired with modes of operation, such as GCM, to handle variable-length data securely.

Stream Cipher Algorithms

Stream ciphers generate a continuous keystream that is combined with via XOR, making them ideal for real-time applications such as network packets where arrives in variable lengths. Unlike block ciphers, which process fixed-size blocks and require for incomplete , ciphers eliminate the need for , reducing overhead and simplifying for streaming or packet-based encryption. Major cryptography libraries prioritize modern ciphers with 256-bit keys for enhanced , focusing on algorithms resistant to known attacks while deprecating legacy options. Prominent stream cipher algorithms include , Salsa20, and the deprecated . , an with associated data (AEAD) construction combining the ChaCha20 stream cipher and Poly1305 , emerged as a and standard in 2014 for TLS implementations, offering high performance on software platforms without . Salsa20, designed by in 2005 as a high-speed , serves as the predecessor to ChaCha20 and supports 256-bit keys with configurable rounds (typically 20 for security). , once widely used for its simplicity, has been deprecated across libraries due to exploitable biases in its keystream output, which enable statistical attacks recovering with sufficient data. Library support varies, with modern implementations favoring for its balance of speed and security. Libsodium, a portable of the NaCl , exclusively recommends ChaCha20 for AEAD operations like crypto_aead_chacha20poly1305, though it retains Salsa20 for legacy compatibility; NaCl originally used XSalsa20-Poly1305 but transitioned emphasis to ChaCha variants. OpenSSL introduced support in version 1.1.0 released in 2016, enabling its use in TLS 1.3 cipher suites, but does not include Salsa20. Bouncy Castle provides comprehensive support for the full suite, including ChaCha20Engine, Salsa20Engine, and legacy implementations via its StreamCipher interface, allowing developers to select based on application needs.
LibraryChaCha20-Poly1305Salsa20RC4 (Deprecated)
Libsodium/NaClYes (Primary AEAD)Yes (Legacy)No
Yes (Since 1.1.0)NoYes (Disabled by default)
Bouncy CastleYesYesYes
These advantages make stream ciphers particularly suitable for packet encryption in protocols like TLS, where low latency and adaptability to varying sizes are critical. Security analyses emphasize proper nonce management, as stream ciphers like ChaCha20 are vulnerable to nonce misuse attacks; reusing a nonce with the same key allows an attacker to XOR ciphertexts and recover plaintext differences, compromising . No practical breaks on the full 20-round ChaCha20 have been published, and 2024 audits of implementations like noble-ciphers confirm resistance to new vulnerabilities when nonces are unique.

Cipher Operation Modes and Primitives

Block Cipher Modes

Block cipher modes of operation extend the use of underlying block ciphers, such as AES, to process data larger than a single block while providing ; some modes also incorporate to ensure . These modes address limitations of raw block encryption, such as handling variable-length messages and mitigating patterns in repeated blocks, though choices impact , , and parallelism. Common unauthenticated modes include Electronic Codebook (ECB), which encrypts each block independently but is insecure as identical plaintext blocks produce identical ciphertext, revealing patterns. Cipher Block Chaining (CBC) chains blocks by XORing each plaintext block with the previous ciphertext before encryption, requiring a random initialization vector (IV) for security and padding for non-block-aligned data. Counter (CTR) mode generates a keystream by encrypting a counter, enabling stream-like operation and parallel processing, provided the counter (nonce) is unique per key to avoid keystream reuse. Authenticated Encryption with Associated Data (AEAD) modes combine and in a single primitive. Galois/Counter Mode (GCM) uses CTR for encryption and a polynomial-based over a Galois field for , supporting associated data and allowing parallel computation. Counter with (CCM) pairs CTR encryption with a CBC-based MAC, offering similar AEAD capabilities but typically requiring two passes, which can limit parallelism compared to GCM. Both modes are sensitive to nonce or IV reuse, which can lead to recovery or key exposure if not managed properly. These modes are standardized in the NIST SP 800-38 series, with SP 800-38A covering ECB, CBC, CFB, OFB, and CTR; SP 800-38D specifying GCM; and SP 800-38C defining CCM. GCM is particularly prominent, as TLS 1.3 mandates support for the TLS_AES_128_GCM_SHA256 in all compliant implementations, with TLS_AES_256_GCM_SHA384 strongly recommended. AEAD modes like GCM offer efficiency by providing both and in one pass, reducing computational overhead compared to separate and MAC operations, though they require careful nonce management to prevent catastrophic failures from reuse.
LibraryECBCBCCTRGCM (AEAD)CCM (AEAD)Notes
YesYesYesYes ( via AES-NI)YesComprehensive low-level support; GCM leverages CPU instructions for .
libsodiumNoNoNoYes (AES-256-GCM)NoHigh-level focused on secure AEAD; avoids unauthenticated modes to prevent misuse; emphasizes unique nonces.
Bouncy CastleYesYesYesYesYesFull support across /C# s for all modes.
Crypto++YesYesYesYesYesExtensive C++ implementation of standard modes.
BotanYesYesYesYesYesSupports unauthenticated and AEAD modes with configurable and tag sizes.
In practice, libraries like provide hardware acceleration for GCM on supported platforms, enhancing throughput for high-volume applications, while libsodium's design prioritizes ease-of-use by exposing only AEAD interfaces and documenting nonce uniqueness requirements without built-in reuse detection. Nonce reuse handling relies on application logic across libraries, as GCM and CCM decryption may produce incorrect results or leak information without explicit errors for reuse scenarios.

Message Authentication Codes (MACs)

Message authentication codes (MACs) ensure the and authenticity of by producing a tag from a and a secret key, allowing verification that the has not been altered and originates from a trusted source. In libraries, MAC support focuses on secure, efficient implementations of algorithms that resist attacks, with key sizes typically matching the underlying primitive's level—such as 256 bits for AES-CMAC or at least 32 bytes for HMAC-SHA256. These mechanisms are essential for protocols requiring origin authentication without encryption, though they are often integrated into modes for broader use. Hash-based MACs like , defined in RFC 2104 and standardized by NIST in FIPS 198, combine a (e.g., or ) with a secret key to generate a tag resistant to known hash weaknesses when properly implemented. Cipher-based alternatives include CMAC, specified in NIST SP 800-38B, which uses a like AES in a mode that provides authenticity for binary data, supporting key sizes of 128, 192, or 256 bits to align with AES security levels. Poly1305, a polynomial-based authenticator frequently paired with the ChaCha20 as outlined in RFC 7539, employs a 32-byte key to produce a 16-byte tag, offering high-speed authentication suitable for resource-constrained environments. Major cryptography libraries provide broad support for these MAC algorithms through dedicated APIs, enabling developers to compute and verify tags efficiently. implements , CMAC, and Poly1305 via its EVP interface, with and CMAC available in both default and FIPS providers. Bouncy Castle offers comprehensive coverage, including with various hashes, AES-CMAC, Poly1305, and even GMAC for Galois/Counter Mode , making it versatile for Java-based applications. Libsodium supports variants like HMAC-SHA-256 and HMAC-SHA-512, along with Poly1305 for one-time , but lacks native CMAC. The Python library similarly includes (via hash primitives), CMAC for block ciphers, and Poly1305, facilitating secure MAC operations in scripts. Performance varies by algorithm and hardware, but HMAC-SHA256 typically achieves throughput of 1-2 GB/s on modern x86 CPUs, benefiting from optimized hash instructions like Intel SHA extensions, while Poly1305 can exceed this in software due to its simplicity. For security, libraries emphasize resistance to length-extension attacks inherent in Merkle-Damgård hashes; with or is recommended, as and bases are deprecated post-2025 due to collision vulnerabilities and NIST's phase-out mandate by 2030.
Library (SHA-2/SHA-3)CMAC (AES-based)Poly1305 (with ChaCha20)
OpenSSLYesYesYes
Bouncy CastleYesYesYes
libsodiumYes (/512)NoYes
Python cryptographyYesYesYes

Hashing and Key Management

Hash Functions

Cryptographic hash functions are essential primitives in libraries for ensuring , providing , and serving as building blocks for other constructs like message authentication codes. Major libraries support NIST-approved algorithms such as variants (SHA-256, SHA-384, SHA-512) with output sizes of 256, 384, and 512 bits respectively, offering strong preimage and based on the Merkle-Damgård construction. , standardized in FIPS 202 since 2015 and based on the Keccak sponge construction, provides similar output sizes (e.g., 256 bits for SHA3-256) and is noted for its resistance to length-extension attacks, with claims of enhanced security margins against quantum attacks due to its design. BLAKE2, specified in RFC 7693, serves as a faster alternative to and , supporting variable output lengths up to 512 bits for BLAKE2b and maintaining equivalent security levels while being optimized for software performance on 64-bit platforms. BLAKE3, a parallelizable successor to BLAKE2, offers even higher performance for multi-core systems and is increasingly supported in modern libraries as of 2025. Legacy algorithms like and are included in many libraries for compatibility but are considered broken due to practical collision attacks; NIST has deprecated for all uses, mandating phase-out by December 31, 2030, in favor of and as primary standards post-2025. Incremental hashing for streaming data is widely supported across libraries, allowing efficient processing of large inputs without loading entire datasets into memory. For instance, has provided support since version 1.1.1 and BLAKE2 since 1.1.0, enabling developers to compute digests via the EVP interface for both one-shot and multi-part operations.
LibrarySHA-2 Support (256/384/512)SHA-3 Support (since version)BLAKE2 SupportBLAKE3 SupportIncremental HashingNotes
YesYes (1.1.1)Yes (BLAKE2b/s, 1.1.0)NoYesComprehensive EVP_MD ; legacy SHA-1/MD5 included but deprecated.
libsodiumYes (SHA-256/512)NoYes (BLAKE2b primary)NoYesFocuses on BLAKE2b via crypto_generichash for high performance; avoids legacy algorithms.
Bouncy CastleYesYesYes (BLAKE2b/s)YesYesFull FIPS 202 compliance for SHA-3 variants including SHAKE; supports Blake3.
YesYes (3.0+)NoNoYesSHA-3 added for embedded use; prioritizes SHA-2 for efficiency.
Crypto++YesYesYesYesYesExtensive support including parallel processing optimizations.
Python cryptographyYesYesYes (BLAKE2b/s)Yes (via hashlib)YesHazmat primitives for secure, high-level use; integrates with hashlib.
NettleYesYes (3.1.1)NoNoYesLow-level with SHAKE XOF; used in .
These implementations vary in performance and focus: libsodium emphasizes BLAKE2b's speed (up to 10x faster than on some hardware) for modern applications, while and Bouncy Castle offer broader compatibility with NIST standards. Libraries like and Nettle prioritize lightweight, embedded-friendly designs with selective modern algorithm inclusion. Overall, post-2025 recommendations favor or BLAKE2 for new systems to ensure long-term collision and preimage resistance, with BLAKE3 suitable for performance-oriented uses.

Key Derivation and Agreement Protocols

Key derivation functions (KDFs) and key agreement protocols are essential components in cryptography libraries, enabling the secure generation of cryptographic keys from passwords, shared secrets, or other inputs while resisting brute-force and side-channel attacks. KDFs transform low-entropy inputs, such as passwords, into uniform, high-entropy keys suitable for encryption or authentication, often incorporating salting and computational hardness to deter exhaustive searches. Key agreement protocols, like Diffie-Hellman, allow parties to establish shared secrets over insecure channels, frequently combined with KDFs for key material expansion in protocols such as TLS. Libraries vary in their support for these primitives, prioritizing standards like those from the IETF and (PHC), with modern implementations favoring memory-hard functions to counter GPU-accelerated attacks. Prominent KDFs include PBKDF2, defined in RFC 2898, which applies a pseudorandom function (typically HMAC-based) iteratively to a password and salt, with a minimum of 1000 iterations recommended to impose computational slowness and resist brute-force attempts. HKDF, specified in RFC 5869, follows an extract-then-expand paradigm: it first extracts a pseudorandom key from input keying material using HMAC-Hash(salt, input), then expands it to the desired output length via counter-based HMAC invocations, making it ideal for deriving keys from high-entropy sources like Diffie-Hellman outputs. Argon2, the winner of the 2015 PHC and standardized in RFC 9106, is a memory-hard function designed to prevent time-memory trade-offs, configurable via time cost (t, e.g., 1-3 for balance), memory cost (m, e.g., 64 MiB to 2 GiB), and parallelism (p); its Argon2id variant combines data-dependent and independent modes for resistance to both GPU and side-channel attacks. Scrypt, another memory-hard KDF, complements these by requiring significant RAM during computation to hinder parallelization on specialized hardware. Key agreement protocols supported across libraries often center on Diffie-Hellman (DH), which enables two parties to compute a from public parameters without direct exchange, providing when ephemeral keys are used. In TLS 1.3 (RFC 8446), DH (or ECDH) shared secrets are processed through for key derivation, ensuring secure session keys. Examples include libsodium's crypto_scalarmult_curve25519, which implements X25519-based DH for efficient, constant-time agreement, and OpenSSL's EVP_PKEY interface for finite-field or elliptic-curve DH. These protocols build on hash functions as underlying primitives for , extending their utility in . Security for these mechanisms emphasizes brute-force resistance, particularly for password-based KDFs; Argon2's tunable parameters allow costs to scale with hardware threats, with 2025 guidelines recommending Argon2id as the primary choice for new systems due to its robustness against parallel attacks, over legacy options like PBKDF2. Salts must be randomly generated and at least 8 octets long to prevent precomputation, a practice universally enforced in reputable libraries to avoid weak implementations.
LibraryPBKDF2HKDFArgon2ScryptKey Agreement (e.g., DH)
OpenSSLYesYesYes (3.2+)YesYes (EVP_PKEY)
libsodiumNoYesYes (Argon2id)YesYes (X25519)
Bouncy CastleYesYesYesYesYes
Crypto++YesYesNoYesYes
Implementations like Bouncy Castle's Argon2BytesGenerator and support integrate these KDFs seamlessly in environments, while 's EVP_KDF API unifies , , , and under a high-level interface; libsodium's crypto_pwhash defaults to Argon2id for password-derived keys. These libraries ensure constant-time operations where possible to mitigate timing attacks, aligning with 2025 best practices for post-password hashing.

Advanced and Emerging Features

Post-Quantum Cryptography Support

(PQC) addresses vulnerabilities in classical asymmetric algorithms like RSA and ECC, which are susceptible to on quantum computers. Libraries are integrating PQC to support quantum-resistant key encapsulation mechanisms (KEMs) and digital signatures, primarily lattice-based schemes selected by NIST. The National Institute of Standards and Technology (NIST) finalized standards for ML-KEM (based on CRYSTALS-Kyber) in FIPS 203, ML-DSA (CRYSTALS-Dilithium) in FIPS 204, and SLH-DSA (SPHINCS+) in FIPS 205 in August 2024, with FN-DSA () draft FIPS 206 released in August 2025, pending finalization as of November 2025. Major cryptography libraries vary in their readiness for these algorithms, with support focusing on Kyber/ML-KEM for key exchange and Dilithium/ML-DSA or Falcon for signatures. Bouncy Castle has offered comprehensive PQC implementations since version 1.79 in October 2024, including all four NIST-selected algorithms and hybrid modes combining PQC with classical ECC (e.g., X25519 + Kyber). OpenSSL provides experimental access via the Open Quantum Safe (OQS) provider since 2022, with native integration for the finalized ML-KEM, ML-DSA, and SLH-DSA in version 3.5.0 released in April 2025, enabling hybrid TLS 1.3 key exchanges; support for draft FN-DSA (Falcon) is available via providers. Botan supports ML-KEM, ML-DSA, and SLH-DSA since version 3.x in late 2023, with hybrid post-quantum key exchange in TLS 1.3 using ML-KEM or FrodoKEM, though Falcon remains planned as of November 2025. In contrast, libsodium lacks production PQC support as of November 2025 but includes prototypes for ML-KEM on its roadmap, without timelines for full integration. Crypto++ shows no merged PQC support as of November 2025, relying on external forks.
LibraryML-KEM (Kyber)ML-DSA (Dilithium)FN-DSA (Falcon)SLH-DSA (SPHINCS+)Hybrid ModesKey Version/Date
Bouncy CastleYesYesYesYesYes1.79 (October 2024)
YesYesVia providerYesYes3.5.0 (April 2025)
BotanYesYesPlannedYesYes3.x (late 2023)
libsodiumPrototypeNoNoNoNoRoadmap (November 2025)
Crypto++NoNoNoNoNoNone (November 2025)
PQC adoption in 2025 emphasizes hybrid constructions to mitigate risks during transition, as pure PQC schemes introduce challenges like larger key and signature sizes—e.g., ML-KEM-512 public keys at 800 bytes and ML-DSA-44 signatures at 2,420 bytes, compared to 32 bytes for X25519 keys. These increases can inflate bandwidth in protocols like TLS, prompting libraries to prioritize efficient lattice-based options like and over hash-based SPHINCS+ for general use. TLS 1.4 drafts from August 2025 incorporate post-quantum protections, including hybrid key exchanges, signaling mandatory PQC readiness in future standards to counter harvest-now-decrypt-later attacks. Migration guides from NIST and library vendors recommend assessing dependencies and testing hybrids to ensure interoperability.

Side-Channel Attack Resistance

Side-channel attacks, such as timing, , and , exploit physical implementations of cryptographic algorithms rather than mathematical weaknesses, making resistance a critical aspect of library design. libraries mitigate these by incorporating techniques like constant-time operations, which ensure execution time is independent of secret data, thereby preventing timing leaks; masking, which randomizes intermediate values to obscure power consumption patterns; and blinding, which introduces randomness into computations to thwart differential power analysis (DPA). These countermeasures are essential, as even secure algorithms can be broken if implementations leak information through side channels, with seminal work by Kocher et al. demonstrating DPA's effectiveness against unmasked designs in 1999. Among popular libraries, libsodium stands out for its design philosophy of providing all operations in constant time by default, eliminating conditional branches that could leak timing information across algorithms like AES, operations, and hash functions. This approach, rooted in the NaCl library's principles, has been verified through and security audits, confirming resistance to basic timing and cache-based side channels without requiring user configuration. Similarly, Botan implements comprehensive constant-time primitives, including a bitsliced AES that avoids data-dependent branches and uses hardware instructions where available, while employing masking for Karatsuba multiplications and blinding for RSA (with 64-bit masks refreshed every 64 operations) to resist first-order DPA. For (ECC), Botan uses constant-time via methods like the Montgomery ladder, which performs a fixed sequence of additions and doublings independent of the scalar bits. OpenSSL has evolved to include constant-time implementations, such as its no-branching AES-CTR mode introduced to counter timing attacks, and post-Spectre/Meltdown mitigations like cache-line aware memory access to reduce leaks. However, it has faced ongoing challenges, with 2025 disclosures revealing timing side-channels in the SM2 implementation on 64-bit (CVE-2025-9231), allowing potential private key recovery, underscoring the need for continuous patching despite claims of timing resistance in core . Crypto++, in contrast, offers configurable countermeasures, enabling developers to select constant-time modes for operations like and ECC, though it relies more on user enablement for advanced masking or blinding, with audits confirming basic DPA order-1 resistance in default setups. Comparative assessments highlight that only a subset of libraries, including libsodium and Botan, routinely perform post-compilation timing tests to validate resistance, with techniques like constant-time programming being manually implemented and error-prone across the board. For DPA metrics, many libraries achieve order-1 resistance—requiring thousands of traces for key recovery—but higher-order attacks (order-2) remain feasible without masking, as demonstrated in evaluations of unmasked ECC implementations. Project , initiated by in 2016 and updated through 2025, includes test vectors for detecting implementation flaws that enable side channels, such as branch-dependent timing in DSA variants, aiding libraries like and Crypto++ in verification. While post-quantum algorithms introduce new side-channel risks due to larger key sizes amplifying leaks, classical protections like these remain foundational.
LibraryKey TechniquesResistance Level (Example)Audits/Notes
libsodiumConstant-time by designOrder-1 DPA; timing-resistantFormal verification; post-compilation tests
BotanConstant-time, masking, blindingOrder-1 DPA for AES/ECC; blinding for RSATiming tests with MARVIN; side-channel handbook
OpenSSLNo-branching ops, cache mitigationsOrder-1 for AES; vulns in SM2 (2025)Patches for Spectre; integration
Crypto++Configurable constant-timeOrder-1 configurable; basic maskingUser-enabled; audit-confirmed defaults

Hardware and Platform Integration

Hardware Security Module (HSM) and Smart Card Support

Hardware Security Modules (HSMs) and smart cards provide tamper-resistant environments for key storage and cryptographic operations, integrating with cryptography libraries primarily through standardized protocols to ensure keys remain protected without exposure to the host system. The PKCS#11 interface serves as the dominant standard for this integration, defining a platform-independent API for accessing HSMs and smart cards to perform operations like encryption, signing, and key generation. For smart cards, protocols such as Personal Identity Verification (PIV) enable secure authentication and key management, often layered atop PKCS#11, while the SIM Toolkit supports mobile-specific cryptographic interactions on SIM cards, though adoption in general-purpose libraries remains limited. Among major libraries, OpenSSL offers robust HSM support through its engine architecture, allowing dynamic loading of PKCS#11 providers for devices like Thales nShield, where operations such as AES encryption can be offloaded without exporting keys. This enables seamless integration for enterprise applications, such as secure key storage in payment processing or certificate authorities, where the HSM handles symmetric operations like AES-GCM for data encryption. Bouncy Castle supports HSM and smart card integration indirectly via PKCS#11-compatible providers and its BCFKS keystore format, which facilitates FIPS-compliant key storage and can interface with PIV-enabled cards for Java-based systems. For instance, Bouncy Castle's provider allows offloading RSA signing to smart cards in identity management use cases, maintaining key confidentiality. In contrast, libraries like Crypto++ and libsodium lack native PKCS#11 support, relying on external wrappers for HSM access, which limits their direct use in hardware-secured environments. PyCA/cryptography similarly requires third-party PKCS#11 bindings, such as python-pkcs11, to enable HSM operations, making it suitable for Python ecosystems but adding integration overhead. These integrations are critical for enterprise scenarios, including compliance-driven key offload where AES operations via PKCS#11 prevent key exposure during bulk encryption tasks. Despite these capabilities, HSM integrations face limitations, including due to proprietary extensions in implementations, which can complicate migrations between devices from different manufacturers. As of 2025, compliant HSMs from vendors like Entrust nShield, Thales Luna, and Utimaco now support (PQC) algorithms such as ML-KEM and ML-DSA, enabling libraries to transition to quantum-resistant key storage without full hardware replacement. Unlike CPU-based accelerations, HSMs emphasize isolated key handling for high-assurance environments.

CPU and Accelerator Optimization

Cryptography libraries increasingly leverage specialized CPU instructions and accelerator extensions to enhance for computationally intensive operations like , hashing, and , enabling throughput rates suitable for high-volume applications such as secure and . These optimizations exploit hardware features that offload and parallelize , reducing latency and power consumption compared to pure software implementations. On x86 architectures, Intel's AES-NI instructions, introduced in 2008, provide a 3- to 10-fold speedup for AES encryption and decryption by accelerating key expansion, substitution, and round computations. Libraries like automatically detect and utilize AES-NI via runtime CPU feature checks, seamlessly switching to hardware-accelerated paths for AES operations when available on supported processors. such as further boost performance in modern libraries; for instance, AWS-LC employs for AES-XTS, achieving significant gains in workloads on processors. Similarly, the liboqs library optimizes post-quantum algorithms like using for vectorized hashing, yielding up to 2x improvements over AVX2 baselines. As of 2025, processors with support initial acceleration for PQC algorithms like ML-KEM through vectorized implementations in libraries such as . For ARM-based platforms, prevalent in mobile and embedded systems, the ARMv8 Cryptographic Extensions include instructions like PMULL for polynomial multiplication, which accelerates GHASH in AES-GCM modes and operations. Botan, a C++ , incorporates these extensions where supported, falling back to SIMD-optimized software paths (e.g., ) on older ARM CPUs to maintain compatibility without hardware-specific polyfills. In contrast, prioritizes lightweight implementations for IoT devices with constrained CPUs, using configurable modules that avoid heavy reliance on accelerators but support basic ARM for AES to minimize footprint while achieving acceptable speeds on resource-limited hardware. GPU acceleration extends these optimizations to parallel workloads, with NVIDIA's enabling libraries to offload bulk ; for example, custom on modern GPUs reach throughputs exceeding 80 Gbps for side-channel-resistant variants. Benchmarks across libraries demonstrate AES-GCM performance surpassing 10 Gbps on contemporary x86 and hardware with accelerators, as seen in and Botan on i9 or processors, underscoring the scale for real-time applications like VPNs. As of 2025, emerging trends focus on architectures, where ongoing standardization of cryptographic extensions—such as the scalar and vector crypto proposals in the ISA—enable libraries like those from PQShield to integrate post-quantum primitives with vector acceleration for efficient deployment in open hardware ecosystems.
LibraryKey OptimizationsPlatforms SupportedExample Throughput (AES-GCM)
OpenSSLAES-NI auto-detection, x86>10 Gbps on modern (e.g., )
BotanAES-NI, ARMv8 Crypto (PMULL), fallbackx86, 10-50 Gbps on modern CPUs (median ~32 Gbps)
mbed TLSLightweight AES with (IoT-focused)1-10 MB/s on Cortex-M4 at 100-200 MHz
liboqs for hashesx862x over AVX2 for

Implementation Qualities

Code Size and Maintainability

Code size and maintainability are critical factors in evaluating cryptography libraries, as they influence auditability, deployment in resource-limited settings like embedded systems, and long-term sustainability. Smaller codebases facilitate security reviews and reduce the , while higher comment ratios enhance readability for auditors and contributors. Metrics such as static binary size, lines of code (LOC), and comment density are commonly assessed using tools like the size(1) utility for binaries on systems and cloc for analysis. These indicators help determine suitability for constrained environments, where excessive size can limit integration into or IoT devices. Static binary size varies significantly across libraries, reflecting their scope and optimization. For instance, a full static build of typically results in a exceeding 2 MB due to its comprehensive feature set, including legacy algorithms and extensive protocol support. In contrast, libsodium emphasizes minimalism, with its core static compiling to approximately 100-200 KB, making it ideal for embedded applications where is paramount. Rust-based libraries like ring further reduce size through and selective implementations, often yielding binaries under 500 KB while avoiding common vulnerabilities associated with .
LibraryStatic Binary Size (approx.)LOC (approx.)Comment Ratio (approx.)
~2-3 MB~500,00015-20%
libsodium~100-200 KB~50,00025-30%
Crypto++~1-2 MB>1,000,00010-15%
Botan~500 KB - 1 MB~200,00020-30%
ring<500 KB~100,00030-40%
Lines of code serve as a proxy for complexity and maintainability challenges; larger codebases like Crypto++'s over 1 million lines increase the effort required for thorough audits and updates. Comment ratios, derived via cloc, indicate documentation quality—Botan achieves 20-30% comments, aiding comprehension of its modular C++ design, whereas denser libraries like hover around 15-20%, potentially complicating reviews. In embedded contexts, these metrics directly impact feasibility; oversized libraries like may necessitate stripping unused features to fit within limits typical of microcontrollers. Maintainability is further evidenced by vulnerability history and community engagement. has accumulated over 200 (CVEs) since its inception, reflecting its broad adoption and complex evolution, though recent releases show improved patching velocity. Conversely, libsodium maintains a sparse record with fewer than 10 CVEs, attributable to its focused and design principles that minimize misuse. Active community involvement, measured by forks and contributors, underscores ongoing development— boasts over 10,000 forks with hundreds of active contributors as of 2025, while libsodium has around 1,500 forks and steady updates from its core team. By 2025, libraries like ring have gained traction for maintainability, leveraging the language's ownership model to eliminate entire classes of memory-related bugs, with approximately 300 active forks supporting its integration into secure ecosystems.

Portability and Licensing

Portability in cryptography libraries refers to their ability to compile, run, and integrate across diverse operating systems, hardware architectures, and environments with minimal adaptations, which is crucial for developers targeting multi-platform applications. Libraries written in portable languages like or C++ often achieve broad compatibility through virtual machines or standard compilers, while C-based ones may require platform-specific builds or bindings. For instance, Bouncy Castle, implemented in , offers universal portability across any JVM-supported platform, including Windows, , macOS, , and Android, without needing recompilation, making it suitable for cross-platform development. Many prominent libraries support major desktop and mobile operating systems alongside common architectures. , a library, compiles on Windows (via or ), distributions, macOS, and provides bindings for and Android; it accommodates x86, , ARM (including 32-bit and 64-bit variants), and architectures through configure scripts and assembly optimizations. Similarly, libsodium supports systems, Windows, Android (via NDK for all architectures), Apple platforms (, macOS, etc.), and ARM microcontrollers like Cortex-M series, with cross-compilation options via tools like Zig for targets including . Botan, in , builds on / systems (, macOS), Windows (7 and later), (ARMv7, ARMv8-A, ), and Android, while enabling cross-compilation to and . mbed TLS, optimized for resource-constrained devices, runs on , Windows, macOS, RTOS like , and bare-metal systems, supporting x86, ARM, and with configurable features for embedded use. Challenges to portability arise from dependencies on operating system-specific cryptographic APIs and constraints in embedded environments. Some libraries, such as those integrated with Java's JCA/JCE providers, rely on OS-native backends like Windows Cryptography API: Next Generation (CNG), which limits cross-platform consistency and requires fallback implementations for non-Windows systems. In embedded systems, factors like limited , lack of floating-point units, or absence of dynamic linking pose hurdles; for example, full-featured libraries may exceed RAM constraints on microcontrollers, necessitating lightweight variants or no_std configurations in languages like . These issues can complicate deployment in IoT or mobile contexts, where uniform behavior across heterogeneous hardware is essential. Licensing influences adoption by determining redistribution rights, patent protections, and commercial viability. Bouncy Castle operates under a permissive license akin to MIT, allowing free use, modification, and distribution with minimal requirements like retaining copyright notices, and includes explicit patent grants. libsodium uses the , a BSD variant that permits broad reuse without obligations. Botan follows the Simplified BSD license, enabling integration into . mbed TLS is licensed under Apache 2.0, which provides patent grants and compatibility with GPL code. transitioned to Apache 2.0 for version 3.0 and later (released in ), replacing the prior dual SSLeay/OpenSSL license, to enhance permissiveness and align with modern open-source practices; pre-3.0 versions retain the original dual licensing. These permissive models facilitate widespread use in both open-source and commercial projects, often with explicit clauses addressing cryptographic patents. As of 2025, regulatory shifts like the European Union's emphasize (FOSS) for , indirectly boosting adoption of permissively licensed libraries to meet transparency and auditability requirements in connected devices. Concurrently, Rust-based libraries such as those from the RustCrypto project are enhancing portability, with no_std support enabling deployment on embedded systems without the , alongside compatibility for x86, , and , addressing traditional C/C++ challenges in and cross-compilation.

References

  1. https://arxiv.org/pdf/2203.16370
  2. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules
  3. https://dspace.mit.edu/bitstream/handle/1721.1/155457/3634737.3657012.pdf?sequence=1&isAllowed=y
  4. https://csrc.nist.gov/projects/cryptographic-module-validation-program/validated-modules/search/all
  5. https://bench.cr.yp.to/supercop.html
  6. https://csrc.nist.gov/projects/cryptographic-module-validation-program
  7. https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm
  8. https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.140-3.pdf
  9. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4985
  10. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4943
  11. https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/5032
  12. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
  13. https://blog.pcisecuritystandards.org/pci-ssc-releases-new-guidance-on-authentication-and-cryptography
  14. https://www.isms.online/iso-27001/annex-a-2022/8-24-use-of-cryptography-2022/
  15. https://www.privateinternetaccess.com/blog/libsodium-audit-results/
  16. https://www.niap-ccevs.org/Documents_and_Guidance/2025NIAPQuarterlyReportQ1.pdf
  17. https://quready.com/resources/common-criteria-pqc-guide/
  18. https://www.bouncycastle.org/
  19. https://csrc.nist.gov/pubs/sp/800/131/a/r2/final
  20. https://csrc.nist.gov/pubs/fips/186-5/final
  21. https://datatracker.ietf.org/doc/html/rfc6979
  22. https://datatracker.ietf.org/doc/html/rfc8422
  23. https://csrc.nist.gov/csrc/media/events/workshop-on-elliptic-curve-cryptography-standards/documents/papers/session1-miele-paper.pdf
  24. https://www.princeton.edu/~rblee/ELE572Papers/ECCpapers/SUN_ECC_SSLperformance.pdf
  25. https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519
  26. https://botan.randombit.net/news.html
  27. https://csrc.nist.gov/pubs/fips/203/final
  28. https://csrc.nist.gov/pubs/fips/197/final
  29. https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2
  30. https://datatracker.ietf.org/doc/rfc3713/
  31. https://www.schneier.com/wp-content/uploads/2016/02/paper-twofish-paper.pdf
  32. https://cryptocatalog.github.io/ultimate-crypto-comparison/
  33. https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-standardization-conference/documents/papers/on-practical-cost-of-grover.pdf
  34. https://eprint.iacr.org/2015/727.pdf
  35. https://www.wolfssl.com/the-benefit-of-stream-ciphers/
  36. https://security.stackexchange.com/questions/334/advantages-and-disadvantages-of-stream-versus-block-ciphers
  37. https://blog.cloudflare.com/do-the-chacha-better-mobile-performance-with-cryptography/
  38. https://ianix.com/pub/salsa20-deployment.html
  39. https://www.microsoft.com/en-us/msrc/blog/2013/11/security-advisory-2868725-recommendation-to-disable-rc4
  40. https://libsodium.gitbook.io/doc/advanced/stream_ciphers/chacha20
  41. https://www.cossacklabs.com/blog/moving-to-openssl-110/
  42. https://asecuritysite.com/bouncy/bc_salsa20
  43. https://www.jscape.com/blog/stream-cipher-vs-block-cipher
  44. https://crypto.stackexchange.com/questions/32075/what-happens-if-a-nonce-is-reused-in-chacha20-poly1305
  45. https://www.expressvpn.com/blog/chacha20/
  46. https://github.com/paulmillr/noble-ciphers
  47. https://cure53.de/audit-report_noble-crypto-libs.pdf
  48. https://csrc.nist.gov/pubs/sp/800/38/a/final
  49. https://csrc.nist.gov/pubs/sp/800/38/d/final
  50. https://csrc.nist.gov/pubs/sp/800/38/c/final
  51. https://datatracker.ietf.org/doc/html/rfc8446
  52. https://docs.openssl.org/master/man3/EVP_EncryptInit/
  53. https://doc.libsodium.org/
  54. https://www.cryptopp.com/wiki/Main_Page
  55. https://botan.randombit.net/handbook/api_ref/cipher_modes.html
  56. https://csrc.nist.gov/pubs/fips/198/final
  57. https://datatracker.ietf.org/doc/html/rfc2104
  58. https://csrc.nist.gov/pubs/sp/800/38/b/final
  59. https://datatracker.ietf.org/doc/html/rfc7539
  60. https://docs.openssl.org/3.4/man7/EVP_PKEY-HMAC/
  61. https://asecuritysite.com/csharp/bc_macs
  62. https://libsodium.net/guide/MAC.html
  63. https://crypto.stackexchange.com/questions/26336/sha-512-faster-than-sha-256
  64. https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf?__blob=publicationFile&v=10
  65. https://datatracker.ietf.org/doc/draft-irtf-cfrg-blake3/
  66. https://doc.libsodium.org/hashing/generic_hashing
  67. https://cryptography.io/en/latest/hazmat/primitives/cryptographic-hashes/
  68. https://www.lysator.liu.se/~nisse/nettle/nettle.html
  69. https://www.blake2.net/
  70. https://csrc.nist.gov/projects/hash-functions
  71. https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards
  72. https://www.digicert.com/blog/quantum-ready-fndsa-nears-draft-approval-from-nist
  73. https://arxiv.org/abs/2508.16078
  74. https://www.bouncycastle.org/resources/latest-nist-pqc-standards-and-more-bouncy-castle-java-1-79/
  75. https://www.helpnetsecurity.com/2025/04/09/openssl-3-5-0-released/
  76. https://botan.randombit.net/
  77. https://datatracker.ietf.org/doc/html/draft-zhou-tls-tls14-00
  78. https://nacl.cr.yp.to/
  79. https://botan.randombit.net/handbook/side_channels.html
  80. https://github.com/C2SP/wycheproof
  81. https://www.privateinternetaccess.com/blog/wp-content/uploads/2017/08/libsodium.pdf
  82. https://docs.aws.amazon.com/cloudhsm/latest/userguide/pkcs11-key-types.html
  83. https://docs.oasis-open.org/pkcs11/pkcs11-base/v2.40/os/pkcs11-base-v2.40-os.html
  84. https://docs.yubico.com/software/yubikey/tools/pivtool/Introduction.html
  85. https://github.com/mitshell/CryptoMobile
  86. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/security_hardening/configuring-applications-to-use-cryptographic-hardware-through-pkcs-11_security-hardening
  87. https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Program/intro_PKCS11.htm
  88. https://security.stackexchange.com/questions/140533/is-it-possible-to-use-bouncy-castle-crypto-library-with-pkcs11-hsms
  89. https://stackoverflow.com/questions/60597571/integrating-openpgp-functionality-with-pkcs11-to-use-an-hsm-appliance-in-a-net
  90. https://github.com/pyca/cryptography/issues/4967
  91. https://python-pkcs11.readthedocs.io/en/latest/applied.html
  92. https://mobilityrockstars.com/wp-content/uploads/2022/01/HSM-Whitepaper_v2_2022_Cognizant-Mobility_Eduard-Pop.pdf
  93. https://www.entrust.com/company/newsroom/entrust-nshield-hsms-achieve-validation-from-nist-cryptographic-algorithm-validation-program
  94. https://cpl.thalesgroup.com/blog/encryption/luna-hsm-pqc-quantum-safe-encryption
  95. https://utimaco.com/news/press-releases/utimacos-quantum-protect-algorithms-successfully-passed-nist-testing
  96. https://www.cryptomathic.com/blog/key-management-and-use-cases-for-hsms
  97. https://www.intel.com/content/www/us/en/develop/articles/intel-advanced-encryption-standard-instructions-aes-ni.html
  98. https://www.intel.com/content/dam/doc/white-paper/enterprise-security-aes-ni-white-paper.pdf
  99. https://tpmullan.com/2022/11/08/how-to-check-if-aes-ni-is-enabled-for-openssl-on-linux/
  100. https://infosecwriteups.com/accelerating-cloud-cryptography-optimizing-aws-lc-with-intels-avx-512-31901e2ef566
  101. https://builders.intel.com/docs/networkbuilders/post-quantum-cryptography-accelerating-open-quantum-safe-library-with-intel-avx-512-keccak-1600-implementation-1762253806.pdf
  102. https://www.intel.com/content/www/us/en/developer/articles/technical/post-quantum-cryptography-on-intel-hardware.html
  103. https://krishisanskriti.org/vol_image/02Jul201505071522.pdf
  104. https://searchfox.org/comm-central/source/third_party/botan/src/lib/block/aes
  105. https://os.mbed.com/docs/mbed-os/v6.16/apis/tls-tutorial.html
  106. https://www.cdebyte.com/news/850
  107. https://hzhou.wordpress.ncsu.edu/files/2022/12/aes_gpgpu19.pdf
  108. https://www.usenix.org/event/sec08/tech/full_papers/harrison/harrison.pdf
  109. https://cryptography.gmu.edu/athena/sources/Cryptographic_Engineering_Chapter_10.pdf
  110. https://github.com/riscv/riscv-crypto
  111. https://pqshield.com/press-release-pqshield-and-si-five-collaborate-to-advance-post-quantum-cryptography-in-risc-v/
  112. https://medium.com/@thealonemusk/the-2mb-vs-20mb-showdown-mbedtls-and-openssl-face-off-e600fe5922d3
  113. https://openbenchmarking.org/test/pts/botan-1.4.0
  114. https://cryptojedi.org/papers/aesarm-20161019.pdf
  115. https://stackoverflow.com/questions/5414004/openssl-static-library-too-big-any-alternative-or-way-to-reduce-its-size
  116. https://libsodium.gitbook.io/doc/installation
  117. https://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217
  118. https://www.bouncycastle.org/download/bouncy-castle-java/
  119. https://botan.randombit.net/handbook/building.html
  120. https://csrc.nist.gov/CSRC/media/Events/lightweight-cryptography-workshop-2019/documents/papers/cryptography-in-industrial-embedded-systems-lwc2019.pdf
  121. https://www.nxp.com/docs/en/white-paper/POSTQUANCOMPWPA4.pdf
  122. https://www.bouncycastle.org/licence.html
  123. https://www.openssl.org/source/license.html
  124. https://itp.cdn.icann.org/en/files/security-and-stability-advisory-committee-ssac-reports/sac132-25-09-2025-en.pdf
  125. https://kerkour.com/rust-cryptography-2024
Add your contribution
Related Hubs
User Avatar
No comments yet.