5 ms·
Only on the transport layer. See page 10 of their whitepaper [0]. [0]: https://threema.ch/press-files/2_documentation/cryptography_whitepaper.pdf https://three
by throwaway9d0291 6y ago
Only on the transport layer. See page 10 of their whitepaper [0].
[0]: https://threema.ch/press-files/2_documentation/cryptography_whitepaper.pdf https://threema.ch/press-files/2_documentation/cryptography_...
- est31 6y agoFor voice calls it seems to exist though! > The audio stream is encrypted with the SRTP protocol, with DTLS-SRTP being used for the key exchange. The certificates used for the DTLS session are cryptographically linked to the keys used for Threema’s end-to-end encryption by means of including the certificate fingerprints in signaling messages. DTLS version 1.2 is enforced.
- throwaway9d0291 6y agoFrom 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/ https://www.signal.org/blog/asynchronous-security/
- dbrgn 6y agoThreema 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 6y agoYou 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.