Bouncy Castle (cryptography)
| Company type | Nonprofit organization |
|---|---|
| Industry | Cryptography software |
| Founded | October 18, 2013 |
| Headquarters | Victoria , Australia |
| Owner | Legion of the Bouncy Castle Inc. |
| Website | www |
Bouncy Castle represents a suite of APIs designed for integrating cryptography into software applications, compatible with both Java and C#. Created and managed by the Australian nonprofit Legion of the Bouncy Castle Inc., it operates independently of United States cryptography export regulations.
History
The inception of Bouncy Castle dates back to May 2000, when two programmers aimed to avoid duplicating cryptographic libraries across various server-side Java SE projects. One co-founder’s experience with Java ME shaped the architecture to accommodate a diverse array of Java virtual machines, including J2ME. Initially focused solely on Java, the project expanded to include a C# API in 2004.
The initial Java release contained roughly 27,000 lines of code, supporting J2ME, the JCE/JCA, and basic generation of X.509 certificates. By version 1.53, the codebase had grown beyond 390,000 lines, covering an extensive range of cryptographic protocols and standards such as PKCS#10, PKCS#12, CMS, S/MIME, OpenPGP, DTLS, TLS, OCSP, TSP, CMP, CRMF, DVCS, DANE, EST, and Attribute Certificates. The C# API now includes about 145,000 lines and supports nearly all features available in the Java API.
Notable characteristics of the project include:
- Emphasis on adherence to standards and flexibility
- Publicly accessible tools such as issue trackers, developer mailing lists, and a wiki
- Availability of commercial support through the official website
On 18 October 2013, leading developers formed Legion of the Bouncy Castle Inc., a not-for-profit entity based in Victoria, Australia, to govern project ownership and development activities. The organization was officially recognized as an Australian charity by the Australian Charities and Not-For-Profits Commission on 7 November 2013 and received fundraising authorization from Consumer Affairs Victoria on 29 November 2013.
Architecture
Bouncy Castle’s structure consists primarily of two elements that provide essential cryptographic capabilities: the 'light-weight' API and the Java Cryptography Extension (JCE) provider. Further modules built upon the JCE provider enhance features such as support for PGP and S/MIME.
The 'light-weight' API at a low level implements core cryptographic algorithms optimized for simplicity and suitability in environments with limited memory (for example, JavaME) or where JCE libraries are unavailable (including applets). Being purely Java-based code, it functions without constraints imposed by the JVM and initially facilitated strong cryptography free from Jurisdiction Policy restrictions applied to JCE providers.
Building upon these foundational APIs is the JCE-compatible provider, which acts as a practical model for executing standard cryptographic processes. This provider has been utilized in projects like the open-source Certificate Authority EJBCA.
Certified releases
Both C# and Java editions of Bouncy Castle offer versions certified under FIPS 140-2 Level 1 standards. These certified packages incorporate modified low-level APIs to comply with FIPS-mandated controls while preserving a similar modular design. The JCE provider remains largely compatible as a direct replacement for standard versions. The initial FIPS-certified releases were introduced in November 2016, with the most recent certifications assigned identifiers 4616 for Java and 4416 for C#.
Spongy Castle
Since early 2014, the Android platform has incorporated a modified version of Bouncy Castle. Due to conflicts arising from identical class names, official Bouncy Castle cannot be utilized directly by Android applications. To address this, the third-party initiative Spongy Castle provides a version of the library with renamed classes to eliminate these clashes.
Stripy Castle
A FIPS 140-2 compliant variant of Spongy Castle was initially explored. Nevertheless, because of the way Android handles DEX files, achieving FIPS certification requires the provider to be installed independently from the app. This FIPS 140-2 compliant release for Android is now known as Stripy Castle, distributed under the package name org.stripycastle. This approach avoids interference with Android’s native Bouncy Castle implementation and allows applications using Spongy Castle to operate without mandating FIPS-certified components.