Why do I even need to choose?
Warning: This article borrows a lot from our original Choose your iOS Crypto publication, so if you've read that one, feel free to skip ahead to the libraries and ending notes about the actual Android specificities.
When building your next app, you might realise that you need to encrypt the data. There are two main reasons for that:
transmitting sensitive data to the server and back
storing sensitive data
Even though there is a multitude of tools for that (and we obviously recommend that you check out our crypto library Themis, too), not all of them are equal. By just taking some random algorithm from javax.crypto and using StackOverflow example to implement it, you will generate results far from desirable. Building your own cryptosystems is hard (read this essay), and it's very easy to get it wrong.
Choose your destiny!
So, you need to make your choice consciously. While thinking about your cryptographic tools, it's very useful to keep your goal in mind:
So, how do we achieve that?
Professor vs developer dilemma
When designing data protection, what you will end up with is not just 'algorithm' (the good ones are already invented by professionals and delivered to you in any library), but a cryptosystem - a combination of algorithms, storage formats, protocols, etc. Remember about "the goal"?
Algorithms don't fulfill goals, cryptosystems do. Equally, algorithm weaknesses themselves are not the problem (they could be used in a form, in which their vulnerabilities cannot be exploited), cryptosystem weaknesses are the problem: if they do deliver their guarantees, they're fine, if they don't - they're not.
And this is the basis on which you might want to choose either professor way tools or the developer way tools.
The professor-way tools: build your own crypto.
This is DIY approach. These frameworks give you low-level primitives and expect you to connect them wisely into a cryptographic system.
This requires you to know cryptography and computer security well. In essence, professor way is about composing cryptosystems yourself. If you know cryptography well - why not, you might come up with a specific solution for your specific goal, make it elegant and specific. But, with certain drawbacks: when new vulnerabilities are found, or new technical demands arise to security guarantees you've tried to reach, you'll have to address them yourself, maintaining and updating your code on all platforms. What if new challenges are outside of your knowledge set and nobody yet has a good formal answer? Wait for security researchers to complete their work?
The developer-way tools: boring crypto
... case in the previous paragraph is quite far from ideals of boring crypto, something you might want as a regular developer: crypto that simply works, solidly resists attacks, never needs any upgrades. Although existing products (even author of manifesto's own NaCl and it's port LibSodium went through a number of updates) don't yet completely fit the boring crypto description, aiming for minimal user friction is what should make the developer happy.
There are a few frameworks designed specifically with that requirement in mind and our library, Themis, is one of them. We believe that in most cases you're happy with the easy path: press the button and you're done. Moreover, author of the aforementioned quote has designed a beautiful library NaCl, which has several Android ports and deep respect in cryptographic and security community.
You will get there anyway
But why don't you just copy a few bits of code from StackOverflow for the first library that comes to your mind and forget about it? The text is scrambled, your job is done?
Frequently, developers have a concept of "it works, so it's correct". This is definitely not the case with composing cryptosystems: you might throw good plaintext and receive randomly-looking sequences of characters, but that doesn't mean that your cryptography is correct, it only means that your cryptography does something weird to the text. This is not exactly the goal of security system - the goal is to resist professional attacks, who are able to use a well-developed set of tools, algorithms, and attacks to break your protection.
So, it's vital to get this right: only knowing that your cryptography works properly gets you there. It's either a question of trust for the tools or trust in your own knowledge to build one for yourself.
Tools to use and try
In order of appearance in the scheme.
| Name & URL | Approach | Features | Comments |
|---|---|---|---|
| javax.crypto | Professor | Great set of ciphers and complicated primitives. | Requires significant amount of knowledge to operate securely. |
| OpenSSL, Android OpenSSL | Professor | All possible ciphers you could imagine; exists in many languages and platforms. | OpenSSL's LibCrypto has many canonical implementations of cryptographic functions, used in many open source projects. However, it's quite challenging to build things with it for a normal human being. |
| Facebook Conceal | Developer | One cryptosystem for encrypting and authenticating data. | Rather simplistic symmetric cryptography framework by Facebook's engineering team. Utilizes crypto implementations from aforementioned OpenSSL. |
| RNCryptor/JNCryptor | Developer | Available on many languages and platforms. AES-256, HMAC+SHA256, and PBKDF2. | Easy to read and review. Very developer-friendly. Mature ecosystem. |
| LibSodium JNI | Developer | Cross-platform, available for most platforms and languages. Message exchange, data at rest, signatures, primitives. | First "boring crypto" library to emerge. Originally written by crypto scientist Daniel Bernstein, widely respected by the security community. |
| Themis | Developer | Cross-platform (8 languages, easy to use). | Our own "boring crypto" SDK, on which we build our own products. Themis hides actual algorithms, but provides you with high-level solutions for common problems: message exchange (w/ forward secrecy, socket replacement, various async modes), storage (authenticated, context dependent, format preserving - you pick the mode), authentication. |
| KeyCzar | Developer (tough one) | Java, Python, C++. Pre-built cryptosystems for communication and data storage | KeyCzar features high-level blocks and easy scenarios to build on. It's more complicated than simple cryptosystems above but much less risky than most of Professor-way security. Its feature set allows construction of both storage and messaging cryptosystems. |
| OTR4j | Developer | Implementation of OTRv3 protocol. | Good high-level messaging protocol, based on OTR. |
Bonus: more tools we've left outside main scheme!
SpongyCastle: If you really don't feel like doing cryptography the modern way and don't want a standard library for some reason, SpongyCastle is a good Bouncy Castle build for you to play with.
AESCrypt Android: we haven't included it in the infographic since most tools mentioned there provide more features, better usability and have more sophisticated cryptographic systems and guarantees behind them, but good old AESCrypt is also available on Android and sometimes it's sufficient for your needs.
AeroGear: nice high-level wrapper around some features from aforementioned LibSodium and BouncyCastle. The only reason for not including it in the infographic is a lack of good documentation for Android implementation and quite WIP look.
Why no SSL in transport libraries?
In iOS infographic, we've mentioned that well-configured and properly managed SSL could cover transferring data. For Android, we believe, this is not the case: even though Google puts a huge effort into making the developers use SSL properly, there are more vulnerable apps in the wild, less simple networking frameworks that enforce good security behavior and safe defaults to fall back to.
If you can't go without SSL (maybe your server is outside of your reach, or decisions are dictated by choice of algorithms approved by some regulator), consider at least:
using latest standard (TLS 1.2) and never accepting to fail to insecure defaults (e.g. old SSL).
explicitly disabling old cipher suites.
performing SSL pinning.
performing some kind of mutual authentication scheme (SSL/TLS by default only allows clients to authenticate server).
... and using other good practices from this cheat sheet.
However, this itself is failing to insecure default compared to picking a proper crypto library if you notice the irony.
This list also means that relying solely on SSL still involves a lot of good engineering and wasted time, so if you can control both sides of the equation - why put your destiny into hands of protocol with a long history of issues?
Themis and Android
Android platform enables developers to write their apps in both Java and C/C++. Luckily, Android Themis users can enjoy it in both stacks with almost equal syntax and performance.
