Threema: Are received messages exposed, when sender's private key gets compromised?

Question

Note: This question is specific to the Threema Messenger, and relates to their implementation of encryption (using the NaCl ECDH implementation as per their docs).

I refer specifically to their "note on outgoing messages" in their validation document on their website:

It may seem strange that outgoing messages can be decrypted by entering the sender's private key and the recipient's public key, i.e. without knowing the recipient's private key. ...

Now, consider this scenario:

• Alice has received a message from Bob, while Eve records/intercepts traffic as person-in-the-middle on the way to Alice.
• Alice's public key of course is public, but Alice never disclosed the private key.
• Eve somehow gets the private key of Bob.

With Bob's key and the traffic, could Eve now decrypt all content Bob has ever sent to Alice?

In other words, with Threema, is the privacy of received content dependent on the safety of the private key of the SENDER?

Answer 1

Question #1:

With Bob's key and the traffic, could Eve now decrypt all content Bob has ever sent to Alice?

Yes.

It is about "forward secrecy" and it depends on how Threema manages session keys. (From wikipedia: "Forward secrecy protects past sessions against future compromises of secret keys or passwords.")

There are two points to consider:

1. Ephemeral keys.
   • There are NO ephemeral keys. According to Threema's Cryptography Whitepaper:

     Due to the inherently asynchronous nature of mobile messengers, providing reliable Forward Secrecy on the end-to-end layer is difficult. Key negotiation for a new chat session would require the other party to be online before the first message can be sent... Due to these and the following considerations, Threema has implemented Forward Secrecy on the transport layer only

2. Salt for key derivation.

   • There is a DEFAULT salt used to derive end-to-end encryption keys. crypto_box_open() is used there according to validation primer which generates a key with the following default salt:

   static const unsigned char sigma[16] = "expand 32-byte k";
   static const unsigned char n[16] = {0};
   

   Finally, encryption key is calculated by the following pseudo-formula:

   KEY = HSALSA20(DH(privkey, pubkey), n, sigma);

And it means that the cryptographic key of end-to-end encryption never changes between Alice and Bob in Threema.

---

Question #2:

Is the privacy of received content dependent on the safety of the private key of the SENDER?

Yes.

Though I would say it is a broader issue: in any case when a private key is compromised, the privacy is compromised. If RECEIVER's private key is compromised, then received content can be decrypted by third party as well (key = receiver's private key * sender's public key).

Answer 2

For a Diffie-Hellman key exchange the shared secret created will be the same if the same key pairs are used. This means that if Eve gets hold of a private key of either sender or receiver then they can compute the shared secret and decrypt all past and future messages between Alice and Bob. The common way to get around this problem is to use ephemeral keys so that the shared secret is only valid for that specific session.

For Theema however they've decided not to use ephemeral keys on the end-to-end encryption and instead only ensures forward secrecy on the transport layer as stated on their cryptography whitepaper. Their stated justification is:

The risk of eavesdropping on any path through the Internet between the sender and the server, or be-tween the server and the recipient, is orders of magnitude greater than the risk of eavesdropping on the server itself

So to answer your question directly, for Theema's messages there is only forward security on the transport layer so IF an attacker has the encrypted message AND either the sender's or receipient's private key then they can decrypt it.

Answer 3

"An attacker who has captured the network traffic will not be able to decrypt it even if he finds out the long-term secret key of the client or the server after the fact."

source: https://threema.ch/en/faq/why_secure