Provide a generic API for client and server sometimes can be poisonous. The Java version of AeroGear Crypto was built aiming to share the same codebase, although there are big differences between them.

Android is Java, but not everything is inside. The fresh implementations for digital signatures, private key cryptography and key agreement are not fully supported — each manufacturer can add their own crypto provider, bringing more fragmentation to the platform.

Today, there are few alternatives implementing “new” cipher suites for Android. Bouncy Castle has been the only option for Java. Besides, Keyczar looks great on the surface, the API put too much abstraction.

To get the list of available security providers, run the code below:

for (Provider provider : Security.getProviders()) {
    System.out.format("\n----\nProvider: %s", provider.getName());

    final Iterator<Object> i = provider.keySet().iterator();
    while (i.hasNext()) {

        String entry = (String);
        System.out.format("\n%s \t %s",

Unfortunately, Android platform only includes a cut-down version of Bouncy Castle. Upgrade the library is not that easy, due to classloader conflicts — the motivation behind the repackage to Spongy Castle.

KeyPair and CryptoBox were created on AeroGear Crypto to provide a straightforward interface for key agreement, but it didn’t work well. The explicit calls to Bouncy Castle made the situation even worse. Android projects wanted to use Spongy Castle and the implementation have also had counterproductive effects. The picture below might give you an idea.

Provide factories for crypto APIs, was my initial thought. Aborted few minutes later, once I realized how impractical that would be — if the answer is overcomplicated, there’s something very wrong.

Spongy Castle and BouncyCastle classes are pretty much identical with some slightly differences like package renaming and provider renaming — repackage wouldn’t be a problem.

A specific Android profile was created for Maven Shade relocate the packages from org.spongycastle to org.bouncycastle to fool the compiler. The build was also configured to generate a specific jar for mobile devices.

What has changed for AeroGear Android?

Now that Spongy Castle is packaged in a single jar for Android, is not necessary to explicit specify its dependencies. Just make sure to include the classifier.


The reasons for having the same codebase for cryptography on AeroGear, lies in avoid code duplication and overlappings between client-server encryption. Also, Android developers don’t need to care about extra dependencies.

AeroGear Crypto is under development, a current version can be found on Maven Central and the Android codebase has already integrated it.

There’s too much to get done. If you feel like something is not correct or have questions, ping me at aerogear-dev.