Signal is better than telegram. Telegram makes some odd choices (using proprietery encryption, not end to end encrypting everything by default etc), and signal at least got a formal analysis of all the parts of its protocol and how they interact, and signal chose very normal parameters. Unfortunately the formal analysis showed it was vulnerable to an Unknown Key-Share attack, whereby B can trick A into sending message M to C, such that A believes it has actually sent M to B. Dunno if that got fixed but it most likely did years ago as it's an easy thing to remedy.
I do know that everyone doing group messaging with end to end encryption is trying to switch to a new standard called MLS, which is still in the finalization phase but offers some neat new security features. Actually, I think MLS is finalized at this point but still in some sort of discussion phase. Once that's done, everyone needs to switch to it that's doing secure group messaging. I've done some work in tangential group messaging stuff, trying to show lower bounds on how much communication is required to restore a corrupted group in particular models.
Here's the original MLS draft:
https://tools.ietf.org/id/draft-barnes-mls-protocol-00.html
Also, here is a good answer regarding signal and telegram. I don't know how outdated this is though, I don't really work with either that much.
I'm struggling to understand what new vulnerabilities the Unknown Key-Share attack introduces. Like, if B wanted to/was coerced into just letting C read and write their messages to and from A, or hand their keys over to C and forget them themself that was always already an option for B.
It's a bit esoteric, the point is that A can be tricked into thinking it sent a message to someone, but in actuality it was sent to someone else without C needing to coerce anything to B. Like there's a series of mathematically precise steps done, without violating the protocol (well it's a violation but not a noticeable one). The attacker here is presumed to be computationally bounded. We're not modeling a scenario where C can go and break Bs legs for the keys. C is not even the attacker here, B is. B does not actually even get the key in this attack, they trick A into sending it to C without needing any private information from C. The important part is that from As perspective, without violating the protocol, they don't know they shared keys with the wrong person. Also note I'm like 90 percent sure this got fixed years ago.
From the paper:
Suppose Bart (Pb) wants to trick his friend Milhouse
(Pa). Bart knows that Milhouse will invite him to his birthday party using TEXTSECURE
(e.g., because Lisa already told him). He starts the UKS attack by replacing his own
public key with Nelsons (Pe) public key and lets Milhouse
verify the fingerprint of his new public key. This can be
justified, for instance, by claiming to have a new device and
having simply re-registered, as that requires less effort than
restoring an encrypted backup of the existing key material.
Now, as explained in more detail below, if Milhouse invites
Bart to his birthday party, then Bart may just forward this
message to Nelson who will believe that this message was
actually sent from Milhouse. Thus, Milhouse (Pa) believes
that he invited Bart (Pb) to his birthday party, where in fact,
he invited Nelson (Pe).
So the problem is B is essentially forging A's private key by redirecting A's messages to whoever they want to while A thinks they're sending them to B and C thinks the messages are directly from A and has no idea about Bs involvement?
It's not forging the key, they can't make their own messages, or even read the messages A sent them that they're redirecting. Everything else, yeah that's pretty much right.
Could you weigh in on the Signal vs. Telegram catfight from a security perspective?
Signal is better than telegram. Telegram makes some odd choices (using proprietery encryption, not end to end encrypting everything by default etc), and signal at least got a formal analysis of all the parts of its protocol and how they interact, and signal chose very normal parameters. Unfortunately the formal analysis showed it was vulnerable to an Unknown Key-Share attack, whereby B can trick A into sending message M to C, such that A believes it has actually sent M to B. Dunno if that got fixed but it most likely did years ago as it's an easy thing to remedy.
I do know that everyone doing group messaging with end to end encryption is trying to switch to a new standard called MLS, which is still in the finalization phase but offers some neat new security features. Actually, I think MLS is finalized at this point but still in some sort of discussion phase. Once that's done, everyone needs to switch to it that's doing secure group messaging. I've done some work in tangential group messaging stuff, trying to show lower bounds on how much communication is required to restore a corrupted group in particular models.
Here's the original MLS draft: https://tools.ietf.org/id/draft-barnes-mls-protocol-00.html
Also, here is a good answer regarding signal and telegram. I don't know how outdated this is though, I don't really work with either that much.
I'm struggling to understand what new vulnerabilities the Unknown Key-Share attack introduces. Like, if B wanted to/was coerced into just letting C read and write their messages to and from A, or hand their keys over to C and forget them themself that was always already an option for B.
Would you mind elaborating?
It's a bit esoteric, the point is that A can be tricked into thinking it sent a message to someone, but in actuality it was sent to someone else without C needing to coerce anything to B. Like there's a series of mathematically precise steps done, without violating the protocol (well it's a violation but not a noticeable one). The attacker here is presumed to be computationally bounded. We're not modeling a scenario where C can go and break Bs legs for the keys. C is not even the attacker here, B is. B does not actually even get the key in this attack, they trick A into sending it to C without needing any private information from C. The important part is that from As perspective, without violating the protocol, they don't know they shared keys with the wrong person. Also note I'm like 90 percent sure this got fixed years ago.
From the paper: Suppose Bart (Pb) wants to trick his friend Milhouse (Pa). Bart knows that Milhouse will invite him to his birthday party using TEXTSECURE (e.g., because Lisa already told him). He starts the UKS attack by replacing his own public key with Nelsons (Pe) public key and lets Milhouse verify the fingerprint of his new public key. This can be justified, for instance, by claiming to have a new device and having simply re-registered, as that requires less effort than restoring an encrypted backup of the existing key material. Now, as explained in more detail below, if Milhouse invites Bart to his birthday party, then Bart may just forward this message to Nelson who will believe that this message was actually sent from Milhouse. Thus, Milhouse (Pa) believes that he invited Bart (Pb) to his birthday party, where in fact, he invited Nelson (Pe).
Thanks!
I think I get it now.
So the problem is B is essentially forging A's private key by redirecting A's messages to whoever they want to while A thinks they're sending them to B and C thinks the messages are directly from A and has no idea about Bs involvement?
It's not forging the key, they can't make their own messages, or even read the messages A sent them that they're redirecting. Everything else, yeah that's pretty much right.