Security and Privacy Properties of Groups

[IamfromSpace]

I'm curious to understand just how it is that groups work, and what that means for their security and privacy properties. For individual connections, this is all pretty well documented and clear. For groups, it doesn't seem quite as clear to me exactly what compromises or concerns their may be. It also isn't quite clear where groups are built on top of primitives, or if there are specific parts of the primitives that are indented for group behaviors. It seems like the Open Connections RFC describes the current approach, and an "introduction" based approach was considered but eventually rejected?

[epoberezkin]

Replied to email - thank you!

TLDR:

Introducer can MITM the connection in the same way any service that participates in key exchange can MITM it (that is, any service other than SimpleX).

The group UI in the apps will both have the indication whether the connection is direct or via the introducer, and also allow to "secure the connection" by comparing key fingerprints via QR code scan.

Groups do not use Open connections, the "open connections RFC" describes what is implemented as long term user addresses. Even with open connections it would still require introductions, so it would not help improve security here.

[IamfromSpace]

I had a thought that Shamir Secret Sharing might be useful for a couple context—one being introductions. If instead of sending your connection invite through one person, you split it among the parties, then an attack can only MITM if they control every part (assuming fault tolerance isn’t used). This could be useful for allowing groups to securely introduce two parties.

It could serve as a way to make a connection over multiple otherwise insecure methods. This could just be called Multi-Factor Connections, where you can split the invite multiple ways. You can then send each portion via different channel of your choosing: SMS, email, group chats, snail mail, other SimpleX users, etc. Once all collected, they can be reconstructed into the single invite.

Happens to also simplify my groups RFC, which is the benefit in figuring that out over TLA+ rather than shipped code :)

Multi-Factor Invites seem pretty compelling to me though, I’m curious if that take is shared.

[epoberezkin]

It achieves the same as validating the connection after the fact (via another channel), right?

[IamfromSpace]

I believe it’s net better (in the MITM scenario, equivalent in the eavesdropper scenario), since an attacker must be able to completely rewrite messages on all channels to substitute a connection in the middle.

So let’s say that Alice and Bob have two channels they talk over and Alice wants to invite Bob—but face-to-face or video is impossible to impractical. Carol is a MITM on one channel, but they don’t know which one.

Currently, if they invite on the faulty channel and validate on the clean channel, Carol will substitute each queue and forward message to they appear to have connected. Both with confirm on the clean channel, even though their connection is under Carol’s control.

If they use the clean channel, the connection will also be clean, but Carol may have the ability to rewrite messages that make each think the invite was intercepted and there’s an attacker on either end.

With secret splitting, if they have one good channel, Carol can only see or modify half the share of the message. This doesn’t let her swap invites to build intermediate queues that look legitimate. The worst she can do is corrupt the message she sees. Since queue identifiers are random, even if that corruption couldn’t be accounted for, it would simply prevent the invite, rather than allow Carol to fool them.

[IamfromSpace]

Oh, but yes, I see, confirming invite details or connection fingerprints over a secondary channel should do more-or-less the same thing.

I think the appeal in this case is the validation is essentially automatic. You use and confirm every channel you use.