Also: the ZIP library the client uses didn't verify MACs, and while Threema fixed that, the maintainer of the ZIP library Threema chose hasn't responded, which is :grimace-emoji. * One form of Threema backup uses encrypted ZIPs, which reveal the names of files, which files apparently (according to the paper) reveal the identity of counterparties you've been talking to.

The C2S handshake has the raw material to do an authenticated DH key exchange, ala 3DH (both sides have long-term and ephemeral secrets), but they freelanced it instead and come up with a proof-of-identity round trip that is trivially replayable, and which destroys the forward secrecy of the C2S protocol. * Threema has the hello-world of E2E protocols, but for reasons not made clear has chosen to build their own transport protocol for client-server transactions (ie, login), rather than using TLS or NoiseIK. * The Threema E2E protocol includes enough metadata to ostensibly enforce message ordering, but they don't authenticate it, so attackers can (1) strip the metadata off and (2) hold back and/or reorder messages at their luxury.

This breaks down when users change devices, which, due to the structure of the protocol, is trivially detectable. Worse, to prevent otherwise-trivial replay attacks made possible by the simplistic structure of the protocol, both sides have to cache every nonce they've seen used to encrypt a message. * Threema's end-to-end inner protocol, the one used to exchange messages between actual humans, is based on a single X25519 key, used bidirectionally. But somehow, Threema comes out looking even worse: The attacks in this paper are much less damaging than the attacks in the Nebuchadnezzar paper were against Matrix.

Threema vs signal