Crypto in iOS: Choose your destiny (Infographic)

Why do I even need to choose?

When building your next app, you might realize that you need to encrypt the data. There are two main reasons for that:

• transmitting sensitive data to server and back
• storing sensitive data

Even though there is a multitude of tools for that, not all of them are equal. By just taking some random algorithm from CommonCrypto and using StackOverflow example to implement it, you’ll fail. Remember, cryptography is hard (read this essay and this presentation), 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:

protect the sensitive data in certain context from modification and 3rd party eyes, and be able to trust sender of the data.

So, how do we reach 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 — combination of algorithms, storage formats, protocols, etc. Remember about “the goal”?

Algorithms don’t fulfil 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 aforementioned quote has designed a beautiful library NaCl, which has several iOS 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 concept of “it works, so it’s correct”. This is definitely not the case with cryptography: 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 cryptography — the goal is to resist professional attacks, who are able to use 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.

CommonCrypto and Swift wrapper IDZSwift CommonCrypto

• Approach: Professor
• Features: A lot of symmetric ciphers, hashes, password-derivation tools. Asymmetric stuff only in original CommonCrypto. iOS-only.
• Comments: Huge, tangled, original framework in ObjC. You need to use one of various wrappers to work with CommonCrypto in Swift

OpenSSL CocoaPod, OpenSSL for iPhone

• Approach: Professor
• Features: All possible ciphers you could imagine; exists in many languages and platforms...
• Comments: OpenSSL is deprecated on OS X and removed from iOS because of poor libssl, but OpenSSL’s libcrypto library is considered canonical implementation of many cryptographic functions and is still widely used.

AESCrypt for ObjC

• Approach: Developer
• Features: iOS (Objc), Android, Ruby. AES
• Comments: Rather simplistic symmetric cryptography framework.

RNCryptor

• Approach: Developer
• Features: Available on many languages, including ObjC/Swift. AES-256, HMAC+SHA256, and PBKDF2.
• Comments: Easy to read and review. Very developer-friendly. Mature ecosystem.

LibSodium/NaCl

• Approach: Developer
• Features: Cross-platform, a bit tangled. Message exchange, data at rest, signatures, primitives.
• Comments: First “boring crypto” library to emerge. Originally written by cryptoscientist Daniel Bernstein, widely respected by security community.

Themis

• Approach: Developer
• Features: Cross-platform (8 languages including iOS, actively growing), rather easy to use.
• Comments: 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.

OTRKit

• Approach: Developer
• Features: Cross-platform, port of libotr, implementation of OTRv3 protocol
• Comments: Objective-C wrapper for the OTRv3 encrypted messaging protocol, cryptosystem went through numerous assessments and audits, very strong design and quite easy to use.

Well-configured SSL

• Approach: Developer (mostly)
• Features: There are many implementation on virtually any platform.
• Comments: When configured properly with latest set of secure protocols and practices like SSL certificate pinning, SSL might be a good measure if you can’t control server’s crypto stack. Yet, you have to keep an eye on latest security vulnerables and consider reading this article to reconsider your SSL usage.

This post was previously published on our blog.