Background and History

JCO is the outcome of years of frustration trying to make Sun's Java Cryptography Architecture (JCA) and implementations of that architecture such as Bouncy Castle (JCE) do the right thing. This lead to the belief that JCA/JCE is designed to satisfy requirements that I simply don't have. I won't speculate further as to why JCA/JCE is so complex and poorly documented and will concentrate here on how, and why, JCO takes a different approach.

JCO is for those who need to encrypt and decrypt, to sign and verify signatures, to generate new keys from random bytes, and to save/restore keys in files with the strongest cryptography available.

If you really need the ability to choose between any imaginable algorithm by any imaginable provider, stick with JCA/JCE. That provides the flexibility to choose between many different cryptographic algorithms, blocks, padding and modes of block chaining. JCO hardcodes such decisions as things most people don'tcare about (other than that they be handled right). It settles on 128 bit RC4 for symmetric (SecretKey) cryptography, 1024 bit RSA keys for assymetric (PrivateKey and PublicKey) cryptography, and SHA-1 for message digests. If you want something else, JCO iseither not for you, or more likely, a source of examples of how to build a JCO equivalent that does exactly what you need.

The second difference is that JCO keys are not passive key repositories as in JCA/JCE, that are useless until combined with an external Cipher engine. JCO keys are, by design, active objects, not passive data repositories. All cryptographic functionality is available from the three key classes:JCOSecretKey, JCOPrivateKey and JCOPublicKey. Some methods return instances of three supporting classes, JCOEncodedObject, JCOSealedObject, and JCOSignedObject, which define byte[] repositories for encoding, sealing and signing results.

JCO keys are not serializable as in JCA/JCE, nor do they provide toString() methods. These undercut the security-by-obscurity that obfuscators like ProGuard can provide by exempting the class from obfuscation and by leaving helpful clues to variable naming in the toString method. To store keys offline, simply encode them to JCOEncodedObjects and recover them from there.

All JCO classes have the same names as in JCA/JCE with a JCO prefix as a reminder that JCO provides the same functionality as JCA/JCE via a new API that is simpler to understand and use. JCO is not a replacement for Sun's JCA or the BouncyCastle JCE. It simply provides a self-contained, convenient, easy to use, easy to understand API for accessing the BouncyCastleJCE via the BouncyCastle lightweight API.