[throwaway9d0291]

From the 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."

That's not a problem for voice calls because voice calls inherently require both participants to be online.

Though I am curious why Signal's approach [0] wouldn't work for Threema.

[0]: https://www.signal.org/blog/asynchronous-security/

[dbrgn]

Threema predates Signal (and even TextSecure v2).

Using plain NaCl boxes also has certain advantages: The crypto is quite simple and you can encrypt a message statelessly for a recipient if you have their public key.

With the Signal protocol, if I understand it correctly, you need to pre-generate and exchange a number of keys. With this process, I think you can run out of keys if you encrypt a lot of messages without the other party being online. And you need to exchange those keys before you can even communicate with each other.

[est31]

You don't need to have this pregeneration to get 99% of contents into a forward secret system. Signal does it to encrypt the first few messages of a conversation. The rest is handled by advancing the cryptographic ratchet in each message. You could easily have the first message to a user contain the start of a cryptographic ratchet and response messages advancing it.

After the first back and forth communication, it's encrypted forward securely, with a full rekeying happening in each back and forth interaction. This does involve state, yes, but it works 100% asynchronously. In fact I think it's also compatible with the multi device plans that Threema has.