This is part #2 of Awesome Curated: The Tools, the series where I dig deep into the tools that survive our automated curation pipeline. If you missed the start, post #1 was about Docker for Novices — a gem that shows up in 16 lists. Today's number is more modest (7), but the topic is considerably darker: applied cryptography.
A few years back, I was working on an app that handled medical data and had to implement end-to-end encryption between the mobile client and the server. The goal was simple: patient data should never travel in plaintext, not even in the database. The execution was a nightmare. I opened the OpenSSL docs and felt like someone had thrown a quantum physics manual at me — written in German. Elliptic curves, padding parameters, key lengths, AES operation modes... do I really need to know all of this just to encrypt a string? The problem with crypto for developers isn't that it's impossible. It's that the low-level API demands knowledge that 95% of projects will never need — and if you get it wrong, there's no runtime warning. Your code compiles perfectly and your crypto is broken. Silently. That's the most dangerous part.
That's exactly where Themis comes in.
What It Does
Themis is a high-level cryptography library, open source (Apache 2.0), built by Cossack Labs. The pitch is straightforward: it gives you serious cryptographic primitives — ECC, AES, ECDH, ECDSA — but wrapped in an API that a backend dev can actually use without needing a postgrad in mathematics. It covers three main use cases:
- Secure Cell: symmetric encryption for data at rest. Think of it as "I want to store this in the DB and make sure nobody who gets into the database can read it." Uses AES-GCM under the hood.
- Secure Message: asymmetric messaging for data exchange between two parties. ECC + ECDSA for signing, RSA + PSS + PKCS#7 as an alternative. The classic "encrypt it with the recipient's public key."
- Secure Session: sessions with forward secrecy. This is what separates Themis from a generic encryption library. It uses ECDH for key agreement — meaning if someone captures your traffic today and gets hold of the keys tomorrow, they still can't decrypt what they captured. Each session gets ephemeral keys.
The real differentiator is multi-language, multi-platform support. Themis has wrappers for Python, Go, JavaScript (Node and browser), Java, Kotlin, Swift, Objective-C, C++, Ruby, and PHP. If you have a Go server and a Swift mobile app, they speak the same protocol. You don't have to reimplement anything or pray that both implementations are compatible with each other.
# Example: encrypting data at rest with Secure Cell (Python)
from pythemis.scell import SCellSeal
# You generate the key once and store it securely (env var, secrets manager, etc.)
master_key = b'my-secret-key-that-is-32-bytes!!'
cell = SCellSeal(key=master_key)
# Encrypt — context is optional but recommended (binds the data to its context)
original_data = b'very sensitive patient data'
context = b'medical-record-id-12345'
encrypted_data = cell.encrypt(original_data, context=context)
# encrypted_data is bytes — store it in the DB like this
print(encrypted_data) # unreadable bytes
# Decrypt — you need the same key AND the same context
recovered_data = cell.decrypt(encrypted_data, context=context)
print(recovered_data) # b'very sensitive patient data'
// Example: Secure Message between iOS client and server (Swift)
import themis
// On the client: generate your key pair
let keyPair = TSKeyGen(algorithm: .EC)!
let clientPublicKey = keyPair.publicKey
let clientPrivateKey = keyPair.privateKey
// The server has its own pair. The client knows the server's public key.
// Encrypt the message with your private key + the server's public key
let encryptor = TSMessage(
inEncryptModeWithPrivateKey: clientPrivateKey,
peerPublicKey: serverPublicKey // obtained during the initial handshake
)
do {
let originalMessage = "sensitive user data".data(using: .utf8)!
// Only the server (with its private key) can decrypt this
let encryptedMessage = try encryptor.wrap(originalMessage)
// send encryptedMessage to the server via HTTP/WebSocket
} catch {
print("Encryption error: \(error)")
}
Why It's on the List
Seven independent awesome lists don't agree on something by accident. The security community tends to be pretty immune to hype — if something reaches that level of consensus in the crypto tooling ecosystem, it's because it solves a real problem with solid judgment behind it.
The curation system's verdict was WORTH_TRYING, but I flagged it as a GEM after reviewing it in depth, and I stand by that. The main reason is forward secrecy in Secure Session. Most devs who implement crypto in their apps never think about this. They encrypt the data, done. But if an attacker captures encrypted traffic for months and then compromises the server's keys, they can decrypt that entire historical backlog. With forward secrecy, that doesn't happen — the ephemeral keys from each session are discarded. It's a security property that modern TLS implements, but when you're building your own communication protocol you have to think about it explicitly. Themis handles it for you.
Compared to libsodium — the most direct alternative with a larger community — Themis wins in the multi-platform mobile scenario. libsodium's API is excellent, but you have to do more legwork to get an iOS client and a Go server talking to each other properly. Themis handles that interoperability layer out of the box. Against the AWS Encryption SDK, the difference is obvious: Themis is open source, doesn't lock you into any cloud, and you can audit it yourself or pay someone you trust to do it.
On top of that, Cossack Labs has real enterprise security experience. This isn't a one-person project maintained on weekends. They've done formal audits of the library — the reports are available in the repo. That carries weight when you're picking a crypto dependency.
When NOT to Use It
Themis's abstraction is its biggest strength and also its ceiling. If your use case requires fine-grained control over cryptographic parameters — choosing the exact nonce size, using a specific operation mode that Themis doesn't expose, or integrating with an HSM that has a particular API — you're going to hit a wall. For that, libsodium or straight-up OpenSSL/BoringSSL are the right answer, even if you have to deal with the learning curve.
You also need to think about supply chain risk. Adding any external crypto dependency is a serious decision. Themis has audits, has a track record, has active maintenance — but if your organization has strict policies about which security libraries can enter the stack (very common in regulated fintech or healthcare), you need to run this through the appropriate approval process. Alternatives worth evaluating: libsodium for projects where you want maximum control, AWS Encryption SDK if you're already all-in on AWS and that closes the audit question for you.
Closing Thoughts
If you've ever opened the OpenSSL docs and closed the tab thinking "you need to be a cryptography engineer to do this," Themis is for you. It doesn't replace understanding the concepts — you still need to know what symmetric vs asymmetric encryption means, what forward secrecy implies — but it does pull you out of the mess of implementing protocol details by hand. And in crypto, the details are exactly where everything falls apart.
This was post #2 of Awesome Curated: The Tools. Every tool that shows up here went through multi-list consensus, AI analysis, and my own human verdict. The whole series is designed so that when you need a tool in a specific domain, there's a place where someone already did the work of filtering out the noise. The full series lives at /blog/series/awesome-curated-tools.
