What is Threema?

Threema is an end-to-end encrypted messaging application. (That's actually what it stands for: End-to-End Encrypted Messaging Application or EEEMA, which became Threema.)

In a world with so many E2EE messengers, what makes Threema special? Well, as far as I can tell, there are basically 3 selling points for Threema (over, for example, Signal):

1. You have to pay for it.

(Therefore, the company has a non-predatory business model and doesn't need to abuse your privacy. Still, it's pretty hard to convince people to pay for something when better alternatives exist for free.)

2. The company is based in Switzerland, and the centrally controlled servers are operated in Switzerland.

("Switzerland, therefore privacy", as a colleague of mine said sarcastically. For me, the end-to-end encrypted messaging app being centralized at all is a bigger concern than where the servers are located.)

3. You don't need to provide a phone number or otherwise explicitly identify yourself to the service.

(It's hard to pay for things anonymously, but this at least addresses one of the worst things about Signal.)

Threema was started in 2012, but the source code was secret until 2020 when it finally published the source code under the AGPL.^[1] Threema initially did not provide forward secrecy^[2] and had some issues, but last year it announced a new crypto protocol called Ibex which does offer forward secrecy.

I don't take Threema very seriously ("Pay more for worse security" is a hard sell), but some people in the privacy space think it's exciting. Some researchers recently performed a security analysis of Ibex. Here's Threema's blog post and the analysis itself. This analysis includes a security proof (in the random oracle model) of the security of Ibex key exchange:

Theorem 2. The Ibex protocol is a secure continuous key exchange protocol under the GDH assumption, assuming all KDFs are modeled as random oracles.

Basically, if the random oracle model is acceptable^[3], if a computationally bounded adversary were somehow able to compute the secret keys used in Ibex, they would also be able to solve the Gap Diffie-Hellman problem, which is believed to be a hard problem.

How does Ibex work?

Based on the analysis PDF and Threema's cryptography whitepaper, here's my understanding of how Ibex works...

Notation

• Diffie-Hellman here is Elliptic Curve Diffie-Hellman using Curve25519, i.e., X25519. I'll use standard Diffie-Hellman notation, where X = g^x rather than point multiplication notation where X = xP.
• I will represent keypairs like (x, X), meaning X = g^x.
• I'll omit constant KDF parameters and just say Alice and Bob feed their secrets into a KDF to get the outputs they need.
• || denotes concatenation.

Setup

Alice has a long-term identity keypair (a, A).

Bob has a long-term identity keypair (b, B).

Alice and Bob can download each other's public keys at any time and are assumed to have them.

Unilateral mode (Alice initiates contact)

Alice wants to start a conversation with Bob; however, Bob's device may be offline.

1. Alice generates an ephemeral keypair (x, X)
2. Alice computes k_2DH = B^a || B^x
3. Alice sends X to Bob

When Bob comes online, he will also be able to compute k_2DH = A^b || X^b.

If Alice wants to send Bob encrypted messages at this time, she can feed k_2DH into a KDF which will output a new chain key and a message key. She can use the message key to encrypt the message to Bob and forward the KDF chain to generate future message keys. Bob can also compute k_2DH (as discussed previously), so he can compute the same keys and decrypt these messages.

Complete mode (Bob completes the setup)

When Bob comes online, he can decrypt what Alice has sent him by computing k_2DH (along with the message keys to decrypt any messages Alice sent in unilateral mode).

Bob can also complete the setup:

1. Bob generates an ephemeral keypair (y, Y)
2. Bob computes k_4DH = k_2DH || A^y || X^y
3. Bob sends Y to Alice

Alice can now also compute K_4DH = k_2DH || Y^a || Y^x.

Alice and Bob use K_4DH to create 2 different KDF chains, one for sending from Alice to Bob and one for sending from Bob to Alice. These are used for all future messages.

Forward secrecy

Since k_2DH can be computed with Bob's long-term private key b, all messages sent in unilateral mode can be decrypted using Bob's long-term private key. Thus, unilateral mode does not provide "full" forward secrecy.

k_4DH can only be computed with knowledge of Alice's ephemeral private key x or Bob's ephemeral private key y. The KDF chains forward on each new message. Thus, (assuming keys are properly deleted once they're not needed) complete mode provides forward secrecy.

Post-compromise security

Ibex only uses the symmetric KDF ratchet, meaning that someone who learns a KDF chain key can learn all future message keys. Thus, Ibex does not provide post-compromise security.

Deniability

The key exchange is not deniable, as the "4DH" key exchange includes both parties' long-term keys in one of the Diffie-Hellman terms. (This is the A^b or B^a part.)

As far as I can tell, messages are authenticated with a Poly1305-AES MAC. This offers the basic deniability property that Bob cannot prove Alice wrote a given message because Bob could have written it himself.