One of the key takeaways here that I think might be under-emphasized (although Kenny Paterson did say as much):

Even if you use good cryptographic building blocks, and good libraries that implement the building blocks, you can still make horrible mistakes with protocol design.

The best mechanism we have for preventing weak cryptographic protocols is to use formal methods (proofs, checked by a computer).

https://twitter.com/kennyog/status/1612337097247002624

The attacks in this paper are much less damaging than the attacks in the Nebuchadnezzar paper were against Matrix. But somehow, Threema comes out looking even worse:

* 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. It has no forward secrecy. 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. This breaks down when users change devices, which, due to the structure of the protocol, is trivially detectable.

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

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

* 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. 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:.

* You can "lock" your Threema app, but it does so much background processing that attackers can extract your private key if they have access to the device (or, maybe, all its traffic?) --- to wit, Threema does automated backups, the backups are compressed-then-encrypted, Threema processes messages in the background even when locked, one of those messages runs an automatic contact discovery protocol, and attackers can inject contact-discovery messages to do a byte-by-byte CRIME-style recovery of the private key, which is embedded in the same JSON document(!) as contact information in the backup system.

There is a very funny bit in the middle of the paper where they reconstitute the C2S proof-of-identity replay attack, this time minting a new identity proof rather than replaying it. To pull this off, they bounce the C2S protocol off of the E2E protocol: because, and I cannot believe I am saying this, Threema uses PKCS7 padding (ie, "I'm 3 bytes short of my block size, so I'll pad with 03h 03h 03h"), you can trick a Threema client into sending a message which, once encrypted, will have the 01h-delimited format of the identity proof (because 1/254 validly padded messages will happen to end in 01h). I didn't read closely enough to figure out if there was any reason you would go to the trouble of executing this attack variant, and it is entirely possible that they are just showing off. But: that's why you read these kinds of papers! For the stunt cryptography!

A bit of advice: read these papers for the cryptographic design and pitfall ideas, not for verdicts on which messaging systems to use. Maybe there are very good reasons to use Threema besides its flimsy protocol design; the point is: we know how to design better protocols that don't have these problems, and so (1) here are some more examples for the textbooks on why you should domain-separate your keys (for instance, to make it impossible to bounce the C2S protocol off the E2E protocol in the first place), and (2) Threema could drastically improve their system simply by adopting a known-good protocol rather than freelancing their own.

Great stuff.

[1] https://nebuchadnezzar-megolm.github.io/

I haven't read all, but Attack no. 6 requires access to unlocked phone. IMO, if that is the case, I wouldn't consider this as an attack, at least not as something that would stop me using the service

Threema has responded:

https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta... New Paper on Old Threema Protocol

I would be very interested to know what overlap any of these attack surfaces may have with Signal, or other prominent applications.

What issues are fixable, which are more endemic to the classical architectures?

The problem with messengers: The more secure and privacy centered they are, the less likely it is that any of your friends and relatives use them.

Threema messages of Marian Kočner, a contorversial Slovak businessman who allegedly ordered a murder of a local journalist, were somehow obtained with the help of Europol. [0] The part of his trial where a security expert explained how the police got the messages was purposely not made public.

[0] https://spectator.sme.sk/c/22216551/threema-saga-kocner-repo...

Not directly related to the topic but how is it that Threema is the only popular secure messenger where you have a random ID to give to people to communicate with and not a phone number (Signal) or have your name show up across all your contacts / groups (Telegram)?

You're right; this isn't directly related to the topic. It's a recapitulation of every thread we have ever had about Signal, on a story that has very little to do with Signal and that unveils new cryptography research.

Unfortunately, this is a big dynamic on HN, not just on cryptography threads, but especially on threads rooted in stories with intense technical details. It's time consuming to bring yourself up to speed with what the paper says, but it's easy to have something to say about, say, Signal phone numbers. Which means comments here will be heavily biased towards superficial and tangential stuff.

Another one is Tox (completely distributed, no servers involved!): https://tox.chat/

I do like this feature a lot. I think converting to passphrases (random words) as well could be a good idea (to make it easier to share) -- I think it's a good simple way to make decentralized/secure systems.

Telegram is an obvious law enforcement honeypot. Trust me bro, just upload all your contacts to our servers bro, we won't share them with anyone, promise...

Hey, me and the guys are planning a riot at the Capitol. Wanna come? Join my telegram group and we can talk about it in secret thanks to end-to-end encryption! Here's the public link...

Not sure, but it seems like from a usability perspective it's easier for apps to 'just connect' people in your contacts via the phone number. From a privacy perspective, though, it's much better what Threema does.

That's also why I use Tutanota, one of the very few mail providers that you can use without a phone number.

It's not, there's also Session https://getsession.org/

There is also https://www.olvid.io

Tech paper for anyone interested: https://www.olvid.io/assets/documents/2020-12-15_Olvid-speci...

Matrix uses email-style ids

Wickr was decently popular but unfortunately is now owned by Amazon

I think Signal takes its community temperature from their forums rather than other places that people normally talk on the internet like HN, Reddit, or Twitter. It is rather odd and those forums are pretty trash if I'm to be honest. There are a lot of people that fight tooth an nail on there to make Signal as static as possible, meaning no new features or anything else. A particularly interesting one I saw was a user saying Signal has pretty much solved the E2EE part and needs to focus more on privacy and anonymity[0] and a user just said that's not what Signal is about. I've seen users argue about deletion as "well you can't guarantee message wasn't seen, so don't 'trick users'" and argue that data sent to you is unequivocally yours and no one else's (even saying if someone accidentally sends you a nude that this is justification to not delete. Because they want the nude). So I've stopped going there because the environment is toxic at best. But on the other hand, I think places like Reddit/Twitter (and even HN) are critical on Signal in ways that don't make sense. Just creates too much noise (Twitter threads are just full of users asking about usernames no matter the topic. Come on people. I'm frustrated too, but you're just noise).

I love Signal and think it is a great problem. I think it is too slow (e.g. username rollouts...) -- especially with Moxie's famous fuck decentralization speech -- and needs to actually adapt to the moving ecosystem, but people complain about it in weird ways. For better or for worse, right now it is the best game in town simply because messaging apps require networks. We'll see if they last though, because they aren't adapting fast enough. I think this would be a shame. But it is also a shame that Signal is failing so hard.

[0] https://community.signalusers.org/t/signal-needs-to-shift-to...