The Bouncy Castle Crypto package is a Java implementation of cryptographic algorithms. The package is organised so that it contains a light-weight API suitable for use in any environment (including the newly released J2ME) with the additional infrastructure to conform the algorithms to the JCE framework.

Except where otherwise stated, this software is distributed under a license based on the MIT X Consortium license. To view the license, see here. The OpenPGP library also includes a modified BZIP2 library which is licensed under the Apache Software License, Version 2.0.

If you have the full package you will have six jar files, bcprov*.jar which contains the BC provider, jce-*.jar which contains the JCE provider, clean room API, and bcmail*.jar which contains the mail API.

Note: if you are using JDK 1.0, you will just find a class hierarchy in the classes directory.

To view examples, look at the test programs in the packages:

• org.bouncycastle.crypto.test
• org.bouncycastle.jce.provider.test

To verify the packages, run the following Java programs with the appropriate classpath:

• java org.bouncycastle.crypto.test.RegressionTest
• java org.bouncycastle.jce.provider.test.RegressionTest

Some of the algorithms in the Bouncy Castle APIs are patented in some places. It is upon the user of the library to be aware of what the legal situation is in their own situation, however we have been asked to specifically mention the patents below, in the following terms, at the request of the patent holder.

The BC distribution contains implementations of EC MQV as described in RFC 5753, "Use of ECC Algorithms in CMS". In line with the conditions in:

https://www.ietf.org/ietf-ftp/IPR/certicom-ipr-rfc-5753.pdf

We state, where EC MQV has not otherwise been disabled or removed: "The use of this product or service is subject to the reasonable, non-discriminatory terms in the Intellectual Property Rights (IPR) Disclosures of Certicom Corp. at the IETF for Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) implemented in the product or service."

The Bouncy Castle provider can make use of the following two system properties:

• org.bouncycastle.ec.disable_mqv - setting this property to true will disable support for EC MQV in the provider.
• org.bouncycastle.pkcs1.not_strict - some other providers of cryptography services fail to produce PKCS1 encoded block that are the correct length. Setting this property to true will relax the conformance check on the block length.

• clean room implementation of the JCE API
• light-weight cryptographic API consisting of support for
  • BlockCipher
  • BufferedBlockCipher
  • AsymmetricBlockCipher
  • BufferedAsymmetricBlockCipher
  • StreamCipher
  • BufferedStreamCipher
  • KeyAgreement
  • IESCipher
  • Digest
  • Mac
  • PBE
  • Signers
• JCE compatible framework for a Bouncy Castle provider "BC".
• JCE compatible framework for a Bouncy Castle post-quantum provider "BCPQC".

This API has been specifically developed for those circumstances where the rich API and integration requirements of the JCE are not required.

However as a result, the light-weight API requires more effort and understanding on the part of a developer to initialise and utilise the algorithms.

To utilise the light-weight API in a program, the fundamentals are as follows;

    /*
     * This will use a supplied key, and encrypt the data
     * This is the equivalent of DES/CBC/PKCS5Padding
     */
    BlockCipher engine = new DESEngine();
    BufferedBlockCipher cipher = new PaddedBlockCipher(new CBCCipher(engine));

    byte[] key = keyString.getBytes();
    byte[] input = inputString.getBytes();

    cipher.init(true, new KeyParameter(key));

    byte[] cipherText = new byte[cipher.getOutputSize(input.length)];
    
    int outputLen = cipher.processBytes(input, 0, input.length, cipherText, 0);
    try
    {
        cipher.doFinal(cipherText, outputLen);
    }
    catch (CryptoException ce)
    {
        System.err.println(ce);
        System.exit(1);
    }

The light-weight API has built in support for the following:

The base interface is BlockCipher and has the following implementations which match the modes the block cipher can be operated in.

The base interface for AEAD (Authenticated Encryption Associated Data) modes is AEADBlockCipher and has the following implemenations.

BufferedBlockCipher has a further sub-classes

The following paddings can be used with the PaddedBufferedBlockCipher.

The following cipher engines are implemented that can be used with the above modes.

The following additional key wrapping algorithms are also available: RFC3211WrapEngine, RFC3394WrapEngine, and RFC5649WrapEngine.

The base interface is StreamCipher and has the following implementations which match the modes the stream cipher can be operated in.

The following cipher engines are implemented that can be used with the above modes.

The base interface is AsymmetricBlockCipher and has the following implementations which match the modes the cipher can be operated in.

The following cipher engines are implemented that can be used with the above modes.

The following asymmetric ciphers are also supported and allow variable block sizes:

• IESEngine
• SM2Engine

The base interface is Digest and has the following implementations

The base interface is Mac and has the following implementations

The base class is PBEParametersGenerator and has the following sub-classes

The following password hashing schemes are supported:

The IES cipher is based on the one described in IEEE P1363a (draft 10), for use with either traditional Diffie-Hellman or Elliptic Curve Diffie-Hellman.

Note: At the moment this is still a draft, don't use it for anything that may be subject to long term storage, the key values produced may well change as the draft is finalised.

The base class is Committer and has the following sub-classes

Two versions of Diffie-Hellman key agreement are supported, the basic version, and one for use with long term public keys. Two versions of key agreement using Elliptic Curve cryptography are also supported, standard Diffie-Hellman key agreement and standard key agreement with co-factors.

Agreement using the RFC 7748 Montgomery curve functions is provided by X25519Agreement and X448Agreement, MQV and unified-model variants are available for both Diffie-Hellman and EC, and SM2 key exchange is supported by SM2KeyExchange. Password-authenticated key establishment is provided by the J-PAKE, EC-J-PAKE, SRP-6a, and Owl protocols in subpackages of org.bouncycastle.crypto.agreement.

The agreement APIs are in the org.bouncycastle.crypto.agreement package. Classes for generating Diffie-Hellman parameters can be found in the org.bouncycastle.crypto.params and org.bouncycastle.crypto.generators packages.

The first non-post-quantum set use the EncapsulatedSecretGenerator and EncapsulatedSecretExtractor interfaces.

The second, post-quantum set also use EncapsulatedSecretGenerator and EncapsulatedSecretExtractor.

The standardised versions of Classic McEliece, FrodoKEM, and ML-KEM are implemented under org.bouncycastle.crypto.kems; the Classic McEliece implementation there covers the parameter sets standardised in ISO/IEC 18033-2:2006/Amd 2 (including the pc/pcf plaintext-confirmation variants).

DSA, ECDSA, Ed25519 and Ed448 (RFC 8032), BIP-340 Schnorr, SM2, ISO-9796-2, GOST-3410-94, GOST-3410-2001, GOST-3410-2012, DSTU-4145-2002, RSA-PSS, and BLS12-381 signatures (draft-irtf-cfrg-bls-signature, with the scheme classes in org.bouncycastle.crypto.bls) are supported by the org.bouncycastle.crypto.signers package. Note: as these are light weight classes, if you need to use SHA1 or GOST-3411 (as defined in the relevant standards) you'll also need to make use of the appropriate digest class in conjunction with these. Classes for generating DSA and ECDSA parameters can be found in the org.bouncycastle.crypto.params and org.bouncycastle.crypto.generators packages. Post-quantum signature algorithms (ML-DSA, SLH-DSA, LMS/HSS, XMSS/XMSS^MT, Falcon, Mayo, Snova, and the NIST additional-signatures round candidates) are provided under org.bouncycastle.pqc.crypto.

The org.bouncycastle.crypto.ec package contains implementations for a variety of EC cryptographic transforms such as EC ElGamal.

The org.bouncycastle.crypto.tls package contains implementations for TLS 1.1, 1.2 and DTLS 1.0, 1.2.

The org.bouncycastle.crypto.prng package contains implementations for a variety of bit generators including those from SP 800-90A and X9.31, as well as builders for SecureRandom objects based around them.

The light-weight API has direct interfaces into a package capable of reading and writing DER-encoded ASN.1 objects and for the generation of X.509 V3 certificate objects and PKCS12 files. BER InputStream and OutputStream classes are provided as well.

The Bouncy Castle provider is a JCE compliant provider that is a wrapper built on top of the light-weight API. The main provider is referred to with the name "BC", the post quantum provider is indicated by "BCPQC".

The advantage for writing application code that uses the provider interface to cryptographic algorithms is that the actual provider used can be selected at run time. This is extremely valuable for applications that may wish to make use of a provider that has underlying hardware for cryptographic computation, or where an application may have been developed in an environment with cryptographic export controls.

To utilise the JCE provider in a program, the fundamentals are as follows;

    /*
     * This will generate a random key, and encrypt the data
     */
    Key     key;
    KeyGenerator    keyGen;
    Cipher      encrypt;

    Security.addProvider(new BouncyCastleProvider());

    try
    {
        // "BC" is the name of the BouncyCastle provider
        keyGen = KeyGenerator.getInstance("DES", "BC");
        keyGen.init(new SecureRandom());

        key = keyGen.generateKey();

        encrypt = Cipher.getInstance("DES/CBC/PKCS5Padding", "BC");
    }
    catch (Exception e)
    {
        System.err.println(e);
        System.exit(1);
    }

    encrypt.init(Cipher.ENCRYPT_MODE, key);

    bOut = new ByteArrayOutputStream();
    cOut = new CipherOutputStream(bOut, encrypt);

    cOut.write("plaintext".getBytes());
    cOut.close();

    // bOut now contains the cipher text

The provider can also be configured as part of your environment via static registration by adding an entry to the java.security properties file (found in $JAVA_HOME/jre/lib/security/java.security, where $JAVA_HOME is the location of your JDK/JRE distribution). You'll find detailed instructions in the file but basically it comes down to adding a line:

    security.provider.<n>=org.bouncycastle.jce.provider.BouncyCastleProvider

Where <n> is the preference you want the provider at (1 being the most prefered).

Where you put the jar is up to mostly up to you, although with jdk1.3 and jdk1.4 the best (and in some cases only) place to have it is in $JAVA_HOME/jre/lib/ext. Note: under Windows there will normally be a JRE and a JDK install of Java if you think you have installed it correctly and it still doesn't work chances are you have added the provider to the installation not being used.

Note: with JDK 1.4 and later you will need to have installed the unrestricted policy files to take full advantage of the provider. If you do not install the policy files you are likely to get something like the following:

        java.lang.SecurityException: Unsupported keysize or algorithm parameters
                at javax.crypto.Cipher.init(DashoA6275)

The policy files can be found at the same place you downloaded the JDK.

Modes:

• ECB
• CBC
• OFB(n)
• CFB(n)
• SIC (also known as CTR)
• OpenPGPCFB
• CTS (equivalent to CBC/WithCTS)
• FF1
• FF3-1
• GOFB
• GCFB
• CCM (AEAD)
• EAX (AEAD)
• GCM (AEAD)
• GCM-SIV (AEAD)
• OCB (AEAD)

Where (n) is a multiple of 8 that gives the blocksize in bits, eg, OFB8. Note that OFB and CFB mode can be used with plain text that is not an exact multiple of the block size if NoPadding has been specified.

All AEAD (Authenticated Encryption Associated Data) modes support Additional Authentication Data (AAD) using the Cipher.updateAAD() methods added in Java SE 7.
On Java 7 and later, AEAD modes will throw javax.crypto.AEADBadTagException on an authentication failure. On earlier version of Java, javax.crypto.BadPaddingException is thrown.

Padding Schemes:

• No padding
• PKCS5/7
• ISO10126/ISO10126-2
• ISO7816-4/ISO9797-1
• X9.23/X923
• TBC
• ZeroByte
• withCTS (if used with ECB mode)

When placed together this gives a specification for an algorithm as;

• DES/CBC/X9.23Padding
• DES/OFB8/NoPadding
• IDEA/CBC/ISO10126Padding
• IDEA/CBC/ISO7816-4Padding
• SKIPJACK/ECB/PKCS7Padding
• DES/ECB/WithCTS

Note: default key sizes are in bold.

Note: default key sizes are in bold.

Encoding:

• OAEP - Optimal Asymmetric Encryption Padding
• PCKS1 - PKCS v1.5 Padding
• ISO9796-1 - ISO9796-1 edition 1 Padding

Note: except as indicated in PKCS 1v2 we recommend you use OAEP, as mandated in X9.44.

When placed together with RSA this gives a specification for an algorithm as;

• RSA/NONE/NoPadding
• RSA/NONE/PKCS1Padding
• RSA/NONE/OAEPWithMD5AndMGF1Padding
• RSA/NONE/OAEPWithSHA1AndMGF1Padding
• RSA/NONE/OAEPWithSHA224AndMGF1Padding
• RSA/NONE/OAEPWithSHA256AndMGF1Padding
• RSA/NONE/OAEPWithSHA384AndMGF1Padding
• RSA/NONE/OAEPWithSHA512AndMGF1Padding
• RSA/NONE/OAEPWithSHA3-224AndMGF1Padding
• RSA/NONE/OAEPWithSHA3-256AndMGF1Padding
• RSA/NONE/OAEPWithSHA3-384AndMGF1Padding
• RSA/NONE/OAEPWithSHA3-512AndMGF1Padding
• RSA/NONE/ISO9796-1Padding

Diffie-Hellman key agreement is supported using the "DH", "DHU" (Diffie-Hellman Unified", "ECDH", "ECCDH" (EC Cofactor DH), "ECKAEG" (BSI EC KAEG key agreement"), "ECMQV" and "ECCDHU" (EC Cofactor DH Unified) key agreement instances and their variations. Key exchange, which also uses the KeyAgreement API is supported by "NH" (the NewHope algorithm (BCPQC)). SM2 key exchange is currently supported in the lightweight API.

Support is provided for the standard SEC algorithm set for EC. Names appear in the form of [Agreement]with[KDF PRF Digest][KDF type]. For example:

• "ECCDHwithSHA256KDF" which represents EC cofactor DH using the X9.63 KDF with SHA256 as the PRF
• "ECMQVwithSHA1CKDF" which represents EC MQV using the concetantion KDF with SHA1 as the PRF

Note: with basic "DH" only the basic algorithm fits in with the JCE API, if you're using long-term public keys you may want to look at the light-weight API, there are also additional JCE support classes for UserKeyingMaterial and MQVParameters in the org.bouncycastle.jcajce.spec package.

If used for key wrapping via the Cipher class, you will also need to make use of the KEMParameterSpec class to specify a symmetric wrapping algorithm.

If access to the shared secret is required, KeyGenerator implementations can also be used in conjuction with the KEMGenerateSpec and the KEMExtractSpec which return the shared secret directly.

An implementation of ECIES (stream mode) as described in IEEE P 1363a. This now based more formally on Victor Shoup's paper and should be compatible with the implementation in Crypto++ (version 6 onwards).

Examples:

• DESMac
• DESMac/CFB8
• DESedeMac
• DESedeMac/CFB8
• DESedeMac64
• SKIPJACKMac
• SKIPJACKMac/CFB8
• IDEAMac
• IDEAMac/CFB8
• RC2Mac
• RC2Mac/CFB8
• RC5Mac
• RC5Mac/CFB8
• ISO9797ALG3Mac

Schemes:

• DSTU4145
• Ed25519
• Ed448
• GOST3411withGOST3410 (GOST3411withGOST3410-94)
• GOST3411withECGOST3410 (GOST3411withGOST3410-2001)
• MD2withRSA
• MD5withRSA
• SHA1withRSA
• RIPEMD128withRSA
• RIPEMD160withRSA
• RIPEMD160withDSA
• RIPEMD160withECDSA
• RIPEMD256withRSA
• SHA1withDSA
• SHA224withDSA
• SHA256withDSA
• SHA384withDSA
• SHA512withDSA
• SHA3-224withDSA
• SHA3-256withDSA
• SHA3-384withDSA
• SHA3-512withDSA
• SHA1withDDSA
• SHA224withDDSA
• SHA256withDDSA
• SHA384withDDSA
• SHA512withDDSA
• SHA3-224withDDSA
• SHA3-256withDDSA
• SHA3-384withDDSA
• SHA3-512withDDSA
• NONEwithDSA
• SHA1withDetECDSA
• SHA224withECDDSA
• SHA256withECDDSA
• SHA384withECDDSA
• SHA512withECDDSA
• SHA1withECDSA
• NONEwithECDSA
• SHA224withECDSA
• SHA256withECDSA
• SHA384withECDSA
• SHA512withECDSA
• SHA3-224withECDSA
• SHA3-256withECDSA
• SHA3-384withECDSA
• SHA3-512withECDSA
• SHAKE128withECDSA
• SHAKE256withECDSA
• SHA1withPLAIN-ECDSA
• SHA224withPLAIN-ECDSA
• SHA256withPLAIN-ECDSA
• SHA384withPLAIN-ECDSA
• SHA512withPLAIN-ECDSA
• SHA3-224withPLAIN-ECDSA
• SHA3-256withPLAIN-ECDSA
• SHA3-384withPLAIN-ECDSA
• SHA3-512withPLAIN-ECDSA
• SHA1withECNR
• SHA224withECNR
• SHA256withECNR
• SHA384withECNR
• SHA512withECNR
• SHA224withRSA
• SHA256withRSA
• SHA384withRSA
• SHA512withRSA
• SHA512(224)withRSA
• SHA512(256)withRSA
• SHA3-224withRSA
• SHA3-256withRSA
• SHA3-384withRSA
• SHA3-512withRSA
• SHA1withRSAandMGF1
• SHA256withRSAandMGF1
• SHA384withRSAandMGF1
• SHA512withRSAandMGF1
• SHA512(224)withRSAandMGF1
• SHA512(256)withRSAandMGF1
• SHA1withRSA/ISO9796-2
• RIPEMD160withRSA/ISO9796-2
• SHA1withRSA/X9.31
• SHA224withRSA/X9.31
• SHA256withRSA/X9.31
• SHA384withRSA/X9.31
• SHA512withRSA/X9.31
• SHA512(224)withRSA/X9.31
• SHA512(256)withRSA/X9.31
• RIPEMD128withRSA/X9.31
• RIPEMD160withRSA/X9.31
• WHIRLPOOLwithRSA/X9.31
• SHA512withSPHINCS256 (BCPQC)
• SHA3-512withSPHINCS256 (BCPQC)
• SHA256withSM2
• SM3withSM2
• LMS
• ML-DSA
• HASH-ML-DSA (pre-hash ML-DSA, also available as SHA512withMLDSA)
• Falcon
• SLH-DSA
• XMSS-SHA256
• XMSS-SHA512
• XMSS-SHAKE128
• XMSS-SHAKE256
• XMSSMT-SHA256
• XMSSMT-SHA512
• XMSSMT-SHAKE128
• XMSSMT-SHAKE256
• SHA256withXMSS-SHA256
• SHA512withXMSS-SHA512
• SHAKE128withXMSS-SHAKE128
• SHAKE256withXMSS-SHAKE256
• SHA256withXMSSMT-SHA256
• SHA512withXMSSMT-SHA512
• SHAKE128withXMSSMT-SHAKE128
• SHAKE256withXMSSMT-SHAKE256
• MLDSA44
• MLDSA65
• MLDSA87
• MLDSA44-ECDSA-P256-SHA256
• MLDSA44-Ed25519-SHA512
• MLDSA44-RSA2048-PKCS15-SHA256
• MLDSA44-RSA2048-PSS-SHA256
• MLDSA65-ECDSA-P256-SHA512
• MLDSA65-ECDSA-brainpoolP256r1-SHA512
• MLDSA65-ECDSA-P384-SHA512
• MLDSA65-Ed25519-SHA512
• MLDSA65-RSA3072-PKCS15-SHA512
• MLDSA65-RSA3072-PSS-SHA512
• MLDSA65-RSA4096-PKCS15-SHA512
• MLDSA65-RSA4096-PSS-SHA512
• MLDSA87-ECDSA-P384-SHA512
• MLDSA87-ECDSA-brainpoolP384r1-SHA512
• MLDSA87-ECDSA-P521-SHA512
• MLDSA87-Ed448-SHAKE256
• MLDSA87-RSA3072-PSS-SHA512
• MLDSA87-RSA4096-PSS-SHA512
• SLH-DSA-SHA2-128F
• SLH-DSA-SHA2-128S
• SLH-DSA-SHA2-192F
• SLH-DSA-SHA2-192S
• SLH-DSA-SHA2-256F
• SLH-DSA-SHA2-256S
• SLH-DSA-SHAKE-128F
• SLH-DSA-SHAKE-128S
• SLH-DSA-SHAKE-192F
• SLH-DSA-SHAKE-192S
• SLH-DSA-SHAKE-256F
• SLH-DSA-SHAKE-256S
• SLH-DSA-SHA2-128F-WITH-SHA256
• SLH-DSA-SHA2-128S-WITH-SHA256
• SLH-DSA-SHA2-192F-WITH-SHA512
• SLH-DSA-SHA2-192S-WITH-SHA512
• SLH-DSA-SHA2-256F-WITH-SHA512
• SLH-DSA-SHA2-256S-WITH-SHA512
• SLH-DSA-SHAKE-128F-WITH-SHAKE128
• SLH-DSA-SHAKE-128S-WITH-SHAKE128
• SLH-DSA-SHAKE-192F-WITH-SHAKE256
• SLH-DSA-SHAKE-192S-WITH-SHAKE256
• SLH-DSA-SHAKE-256F-WITH-SHAKE256
• SLH-DSA-SHAKE-256S-WITH-SHAKE256

Schemes:

• BCrypt
• OpenBSDBcyrpt
• SCrypt
• Argon2 (as SecretKeyFactory "ARGON2", RFC 9106, parameters supplied via Argon2KeySpec)
• PKCS5S1, any Digest, any symmetric Cipher, ASCII
• PKCS5S2, any HMac, any symmetric Cipher, ASCII, UTF8
• PKCS12, any Digest, any symmetric Cipher, Unicode

Defined in Bouncy Castle JCE Provider

The Bouncy Castle provider will read X.509 certficates (v2 or v3) as per the examples in the java.security.cert.CertificateFactory class. They can be provided either in the normal PEM encoded format, or as DER binaries.

The CertificateFactory will also read X.509 CRLs (v2) from either PEM or DER encodings.

In addition to the classes in the org.bouncycastle.asn1.x509 package for certificate, CRLs, and OCSP, CRMF, and CMP message generation a more JCE "friendly" class is provided in the package org.bouncycastle.cert. The JCE "friendly" classes found in the jcajce subpackages support RSA, DSA, GOST, DTSU, and EC-DSA.

The Bouncy Castle package has four implementation of a keystore.

The first "BKS" is a keystore that will work with the keytool in the same fashion as the Sun "JKS" keystore. The keystore is resistent to tampering but not inspection.

The second, Keystore.BouncyCastle, or Keystore.UBER will only work with the keytool if the password is provided on the command line, as the entire keystore is encrypted with a PBE based on SHA1 and Twofish. PBEWithSHAAndTwofish-CBC. This makes the entire keystore resistant to tampering and inspection, and forces verification. The Sun JDK provided keytool will attempt to load a keystore even if no password is given, this is impossible for this version. (One might wonder about going to all this trouble and then having the password on the command line! New keytool anyone?).

In the first case, the keys are encrypted with 3-Key-TripleDES.

The third is a PKCS12 compatible keystore. PKCS12 provides a slightly different situation from the regular key store, the keystore password is currently the only password used for storing keys. Otherwise it supports all the functionality required for it to be used with the keytool. In some situations other libraries always expect to be dealing with Sun certificates, if this is the case use PKCS12-DEF, and the certificates produced by the key store will be made using the default provider. In the default case PKCS12 uses 3DES for key protection and 40 bit RC2 for protecting the certificates. It is also possible to use 3DES for both by using PKCS12-3DES-3DES or PKCS12-DEF-3DES-3DES as the KeyStore type.

There is an example program that produces PKCS12 files suitable for loading into browsers. It is in the package org.bouncycastle.jce.examples.

The fourth is the BCFKS key store which is a FIPS compliant key store which is also designed for general key storage and based on ASN.1. This key store type is encrypted and supports the use of SCRYPT and the storage of some symmetric key types.

There are no classes for supporting EC in the JDK prior to JDK 1.5. If you are using an earlier JDK you can find classes for using EC in the following packages:

• org.bouncycastle.jce.spec
• org.bouncycastle.jce.interfaces
• org.bouncycastle.jce

To be able to fully compile and utilise the BouncyCastle S/MIME package (including the test classes) you need the jar files for the following APIs.

• Junit - https://www.junit.org
• JavaMail - https://java.sun.com/products/javamail/index.html
• The Java Activation Framework - https://java.sun.com/products/javabeans/glasgow/jaf.html

The BouncyCastle S/MIME handlers may be set in JavaMail two ways.

• STATICALLY
  Add the following entries to the mailcap file:

      application/pkcs7-signature;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_signature
      application/pkcs7-mime;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_mime
      application/x-pkcs7-signature;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.x_pkcs7_signature
      application/x-pkcs7-mime;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.x_pkcs7_mime
      multipart/signed;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.multipart_signed
  

• DYNAMICALLY
  The following code will add the BouncyCastle S/MIME handlers dynamically:

      import javax.activation.MailcapCommandMap;
      import javax.activation.CommandMap;
  
      public static void setDefaultMailcap()
      {
          MailcapCommandMap _mailcap =
              (MailcapCommandMap)CommandMap.getDefaultCommandMap();
  
          _mailcap.addMailcap("application/pkcs7-signature;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_signature");
          _mailcap.addMailcap("application/pkcs7-mime;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.pkcs7_mime");
          _mailcap.addMailcap("application/x-pkcs7-signature;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.x_pkcs7_signature");
          _mailcap.addMailcap("application/x-pkcs7-mime;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.x_pkcs7_mime");
          _mailcap.addMailcap("multipart/signed;; x-java-content-handler=org.bouncycastle.mail.smime.handlers.multipart_signed");
  
          CommandMap.setDefaultCommandMap(_mailcap);
      }