Three lessons from Threema: Analysis of a secure messenger
breakingthe3ma.app
Three lessons from Threema: Analysis of a secure messenger
1–10 of 55 posts
Re: Three lessons from Threema: Analysis of a secure messenger
#2I 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?
Re: Three lessons from Threema: Analysis of a secure messenger
#3I 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
Re: Three lessons from Threema: Analysis of a secure messenger
#4Threema has responded:
https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta... New Paper on Old Threema Protocol
Re: Three lessons from Threema: Analysis of a secure messenger
#5Threema has responded: https://threema.ch/en/blog/posts/news-alleged-weaknesses-sta... New Paper on Old Threema Protocol
As Kenny Paterson points out, on behalf of the research group, the's "the old Threema protocol" in large part because of the work they did, which makes the "old protocol" thing pretty hollow.
Re: Three lessons from Threema: Analysis of a secure messenger
#6Not 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)?
Re: Three lessons from Threema: Analysis of a secure messenger
#7Not 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)?
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.
Re: Three lessons from Threema: Analysis of a secure messenger
#8Not 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)?
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.
> [...] 'just connect' people in your contacts via the phone number [...]
Threema also allows that.
I think they really nailed that aspect: Tie the primary identity to a key, not a phone number, and then add a discovery layer on top of that.
Re: Three lessons from Threema: Analysis of a secure messenger
#9I 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
From the paper, my reading is that it's meant to highlight a larger weakness in Threema's design (the decision to rely heavily on a long-lived private key, which then needs to be exported with a potentially attacker-controllable password in order to transfer identity).
Edit: notably, this wouldn't be a problem if (1) Threema required a preconfigured password to encrypt the private key with, or (2) used an identity transfer scheme that was detectable on the target device. But since they're just copying a key, it's entirely undetectable.
Re: Three lessons from Threema: Analysis of a secure messenger
#10One 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).