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?

  • I wonder: If Eve just "intercepts" the traffic and has Bob's private key, can she actually decode the traffic intercepted?
    – U. Windl
    Commented May 30, 2022 at 9:55

3 Answers 3


Question #1:

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


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?


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).

  • I am choosing this over the other answers, because it is a bit more detailed (but not too much) and more directly answers the question, but still gives some reasoning.
    – Marcel
    Commented Apr 19, 2020 at 21:33

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.


"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

  • 2
    OK, that's an interesting read. To improve your answer, please copy over the key parts of the linked document. I think, the interesting part here is the layering, and (not covered there) whether this layering is always enforced (or could be attacked itself).
    – Marcel
    Commented Apr 15, 2020 at 8:05
  • 2
    This answer depends on this particular page continuing to exist. Please include the relevant parts of the link in your answer.
    – schroeder
    Commented Apr 15, 2020 at 8:07
  • 1
    Hi and welcome on SE. Answers only citing external source without context are problematic, see previous comment and the FAQ here: security.stackexchange.com/help/how-to-answer To improve, please add a bit of context why you use it and how it relates to the question.
    – Marcel
    Commented Apr 15, 2020 at 8:10
  • 1
    This is quite a contrast to other answers. Might it be that they are talking about the TLS keys here instead of the message encryption keys?
    – Luc
    Commented Apr 15, 2020 at 9:45
  • 2
    @AlexanderFadeev Thanks for the confirmation. So this answer is kind of misleading, because indeed (as you said) the idea is that even Threema themselves can't read messages and not just network-level attackers. Reading the answer again, it specifically says network traffic only, but I missed it on my first read (expecting they just did the expected thing and implemented this), let alone when someone reads it whose full-time job is not IT security...
    – Luc
    Commented Apr 16, 2020 at 10:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .