3 ms·

I'm still of the opinion that encrypted private group chats are an impossible UX problem (1:1 chat is fine). But if I were to trust anyone to find a way to do i

by kibwen 4y ago

I'm still of the opinion that encrypted private group chats are an impossible UX problem (1:1 chat is fine). But if I were to trust anyone to find a way to do it properly, it would be Signal.

OkayPhysicist 4y ago
What makes it impossible? Naively I would think that if you have a secure 1:1 communication protocol, then you can send N*(1:1) secure messages to a group of N people. To solve the "fake group message" problem where an adversarial member of the group sends different messages to different members of the group, or delays the message to some members, the protocol could simply allow for a 2nd level "vouch" message to be sent, such that Alice sends the message to Bob, Alice sends the message to Charlie, Charlie messages Bob a receipt with the receive time and a hash of the chat log, and Bob messages Charlie a receipt with the receive time and a hash of the chat log. If the hashes don't match, or the receive time is unacceptably different, then you highlight the message as suspect. Sure, it takes N^2+N messages, but that's not exactly a massive overhead for text. Multimedia takes N times as much bandwidth as the 1-server, server-many model for the sender, but otherwise isn't terrible.
- waynesonfire 4y ago
  havn't thought about it too much, but seems like merkle tree may be able to tackle this problem.
  - deleted 4y ago
    [deleted]
- ChadNauseam 4y ago
  Ah, but what if I send different vouch messages to different users? There is actually a way to do it, if you assume PKI (which signal provides) and that all messages will be delivered in some bounded time. It’s called the dolev-strong protocol and it guarantees that all honest members of the group will agree with each other. Unfortunately, it requires one round per group member and delivering all messages within a bounded time isn’t easy.
  - OkayPhysicist 4y ago
    Since you'd be receiving vouches from all group members, you'd get some data about who trusts who's message. To the user, you'd probably highlight the message with the "something's fucky" notifier (red background? a caution symbol?) and then have the further "of X vouches you've recieved, these Y disputed the message's (content/existence)" type deal. Which lets you know that Alice and Bob are in contention, which is probably good enough for most situations. "One of these three (or more if you have multiple groups of bad faith actors) sets of users are operating in bad faith" should be plenty of information for a user to make an informed decision. Even if that decision is "wow, how did I end up in a group containing multiple groups of bad actors, I should be elsewhere".
- deleted 4y ago
  [deleted]
- thesz 4y ago
  What you described is a tendermint-consensus-protocol-like round. It requires a direct connection (or some emulation of such channel) between participants. Consensus protocols are tricky, BTW.
- totony 4y ago
  Why not use a merkle tree/blockchain? Usually a meme, but seems like a good solution here: every message is a blob containing the mssage and the hash of the previous received blob. As long as order and messages are the same, the message is valid. A bad actor could screw with you in this naive implementation though
- lloeki 4y ago
  > Naively I would think that if you have a secure 1:1 communication protocol, then you can send N*(1:1) secure messages to a group of N people IIUC this is what iMessage does (at least when Messages in iCloud or whatever it's called is disabled), except s/people/devices: say you have three devices and someone sends you one message, the message is encrypted once per recipient device, and three encrypted messages get sent. Whether it's 1 person with 3 devices, 3 people each with 1 device, or 2 persons with one having 2 devices and the other a single one becomes largely immaterial.
junon 4y ago
Matrix, while kind of a PITA for non-technical people to get into, can do it quite well considering the featureset they support.
- patmorgan23 4y ago
  >while kind of a PITA for non-technical people to get into, In other words, it has a bad UX. Which was the original point about encrypted group chats.
  - cfhhgtyg 4y ago
    Matrix is a protocol, not an App
    - palata 4y ago
      Thanks for the nitpick. Now let's read this again as "Apps implementing the Matrix protocol...". If one app found a way to make a nice UX for it, all the others would follow. So in practice it seems perfectly reasonable to say "Matrix" when talking about the general UX found in apps implementing the Matrix protocol, doesn't it?
      - cfhhgtyg 4y ago
        Not it doesnt't, unless the Protocol itself is responsible for the UX.
throwaway0x7E6 4y ago
it is very trivial if you don't use unnecessarily fancy cryptographic protocols
- sshine 4y ago
  Not if you want it to scale, remain private/hidden, and have no single point of failure.
dpifke 4y ago
Messaging Layer Security (IETF working group) has some interesting solutions to the various associated problems, and it's being developed as an open standard with multiple implementations: https://messaginglayersecurity.rocks/ https://messaginglayersecurity.rocks/
sshine 4y ago
https://simplex.chat/ https://simplex.chat/ is iterating on this. There’s a lot of pros and cons to any design of private group chats from the perspective of privacy, performance and single points of failure.
drawkbox 4y ago
Any "secure" encrypted messenger that allows more than 1 to 1 connections will always have the potential for the "ghost user" problem. System level some use additional connections/recipients for spam/moderation and the moment you allow any invisible/visible group users in, there is a massive potential for an exploit. Additionally you have the potential for forking off messaging to other users at the system level for either oversight or spam/moderation/other. Some of the compromised systems out there use this very well. A sneaky way some of these "secure" messaging apps are also doing this is ghost participants in the chat that can essentially syphon off the messages even without a compromised client. The ghost participant is always under the guise of moderation or anti-spam or telemetry or some other proprietary shim. > The code shows that the messages were secretly duplicated and sent to a “ghost” contact that was hidden from the users’ contact lists. [1] Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats. Other areas that "secure" messaging apps have holes in is the anti-spam/moderation systems that need to view messages and in the clients themselves who have access to the unencrypted content. This is also taking place in other client apps as well: VPN, password managers, extensions, wallets, even build systems and more. Many like VPNs have logs sent elsewhere but deleted locally -- access to entire machine and all network access. People are way too trusting of "secure" systems/apps that are very common today based on trust. All of these apps/systems would pass code checks, reviews, security inspections and essentially be encrypted/"secure" though a copy is sent off to another area for review. At runtime the leak is in the direction of the data. Then you also have governmental oversight that opens up holes that can be exploited. On Ghost Users and Messaging Backdoors [2] > to add a “ghost user” (or in some cases, a “ghost device”) to an existing group chat or calling session. In systems where group membership can be modified by the provider infrastructure, this could mostly be done via changes to the server-side components of the provider’s system. > I say that it could mostly be done server-side, because there’s a wrinkle. Even if you modify the provider infrastructure to add unauthorized users to a conversation, most existing E2E systems do notify users when a new participant (or device) joins a conversation. Generally speaking, having a stranger wander into your conversation is a great way to notify criminals that the game’s afoot or what have you, so you’ll absolutely want to block this warning. > While the GCHQ proposal doesn’t go into great detail, it seems to follow that any workable proposal will require providers to suppress those warning messages at the target’s device. This means the proposal will also require changes to the client application as well as the server-side infrastructure. > (Certain apps like Signal are already somewhat hardened against these changes, because group chat setup is handled in an end-to-end encrypted/authenticated fashion by clients. This prevents the server from inserting new users without the collaboration of at least one group participant. At the moment, however, both WhatsApp and iMessage seem vulnerable to GCHQ’s proposed approach.) [1] https://www.vice.com/en/article/v7veg8/anom-app-source-code-operation-trojan-shield-an0m https://www.vice.com/en/article/v7veg8/anom-app-source-code-... [2] https://blog.cryptographyengineering.com/2018/12/17/on-ghost-users-and-messaging-backdoors/ https://blog.cryptographyengineering.com/2018/12/17/on-ghost...

by kibwen 4y ago

I'm still of the opinion that encrypted private group chats are an impossible UX problem (1:1 chat is fine). But if I were to trust anyone to find a way to do it properly, it would be Signal.

OkayPhysicist 4y ago

What makes it impossible? Naively I would think that if you have a secure 1:1 communication protocol, then you can send N*(1:1) secure messages to a group of N people. To solve the "fake group message" problem where an adversarial member of the group sends different messages to different members of the group, or delays the message to some members, the protocol could simply allow for a 2nd level "vouch" message to be sent, such that Alice sends the message to Bob, Alice sends the message to Charlie, Charlie messages Bob a receipt with the receive time and a hash of the chat log, and Bob messages Charlie a receipt with the receive time and a hash of the chat log. If the hashes don't match, or the receive time is unacceptably different, then you highlight the message as suspect. Sure, it takes N^2+N messages, but that's not exactly a massive overhead for text. Multimedia takes N times as much bandwidth as the 1-server, server-many model for the sender, but otherwise isn't terrible.

waynesonfire 4y ago
havn't thought about it too much, but seems like merkle tree may be able to tackle this problem.
- deleted 4y ago
  [deleted]
ChadNauseam 4y ago
Ah, but what if I send different vouch messages to different users? There is actually a way to do it, if you assume PKI (which signal provides) and that all messages will be delivered in some bounded time. It’s called the dolev-strong protocol and it guarantees that all honest members of the group will agree with each other. Unfortunately, it requires one round per group member and delivering all messages within a bounded time isn’t easy.
- OkayPhysicist 4y ago
  Since you'd be receiving vouches from all group members, you'd get some data about who trusts who's message. To the user, you'd probably highlight the message with the "something's fucky" notifier (red background? a caution symbol?) and then have the further "of X vouches you've recieved, these Y disputed the message's (content/existence)" type deal. Which lets you know that Alice and Bob are in contention, which is probably good enough for most situations. "One of these three (or more if you have multiple groups of bad faith actors) sets of users are operating in bad faith" should be plenty of information for a user to make an informed decision. Even if that decision is "wow, how did I end up in a group containing multiple groups of bad actors, I should be elsewhere".
deleted 4y ago
[deleted]
thesz 4y ago
What you described is a tendermint-consensus-protocol-like round. It requires a direct connection (or some emulation of such channel) between participants. Consensus protocols are tricky, BTW.
totony 4y ago
Why not use a merkle tree/blockchain? Usually a meme, but seems like a good solution here: every message is a blob containing the mssage and the hash of the previous received blob. As long as order and messages are the same, the message is valid. A bad actor could screw with you in this naive implementation though
lloeki 4y ago
> Naively I would think that if you have a secure 1:1 communication protocol, then you can send N*(1:1) secure messages to a group of N people IIUC this is what iMessage does (at least when Messages in iCloud or whatever it's called is disabled), except s/people/devices: say you have three devices and someone sends you one message, the message is encrypted once per recipient device, and three encrypted messages get sent. Whether it's 1 person with 3 devices, 3 people each with 1 device, or 2 persons with one having 2 devices and the other a single one becomes largely immaterial.

junon 4y ago

Matrix, while kind of a PITA for non-technical people to get into, can do it quite well considering the featureset they support.

patmorgan23 4y ago
>while kind of a PITA for non-technical people to get into, In other words, it has a bad UX. Which was the original point about encrypted group chats.
- cfhhgtyg 4y ago
  Matrix is a protocol, not an App
  - palata 4y ago
    Thanks for the nitpick. Now let's read this again as "Apps implementing the Matrix protocol...". If one app found a way to make a nice UX for it, all the others would follow. So in practice it seems perfectly reasonable to say "Matrix" when talking about the general UX found in apps implementing the Matrix protocol, doesn't it?
    - cfhhgtyg 4y ago
      Not it doesnt't, unless the Protocol itself is responsible for the UX.

throwaway0x7E6 4y ago

it is very trivial if you don't use unnecessarily fancy cryptographic protocols

sshine 4y ago
Not if you want it to scale, remain private/hidden, and have no single point of failure.

dpifke 4y ago

Messaging Layer Security (IETF working group) has some interesting solutions to the various associated problems, and it's being developed as an open standard with multiple implementations: https://messaginglayersecurity.rocks/ https://messaginglayersecurity.rocks/

sshine 4y ago

https://simplex.chat/ https://simplex.chat/ is iterating on this. There’s a lot of pros and cons to any design of private group chats from the perspective of privacy, performance and single points of failure.

drawkbox 4y ago

Any "secure" encrypted messenger that allows more than 1 to 1 connections will always have the potential for the "ghost user" problem. System level some use additional connections/recipients for spam/moderation and the moment you allow any invisible/visible group users in, there is a massive potential for an exploit. Additionally you have the potential for forking off messaging to other users at the system level for either oversight or spam/moderation/other. Some of the compromised systems out there use this very well. A sneaky way some of these "secure" messaging apps are also doing this is ghost participants in the chat that can essentially syphon off the messages even without a compromised client. The ghost participant is always under the guise of moderation or anti-spam or telemetry or some other proprietary shim. > The code shows that the messages were secretly duplicated and sent to a “ghost” contact that was hidden from the users’ contact lists. [1] Lots of "secure" messaging apps do this for intel and surveillance and not just the white hats. Other areas that "secure" messaging apps have holes in is the anti-spam/moderation systems that need to view messages and in the clients themselves who have access to the unencrypted content. This is also taking place in other client apps as well: VPN, password managers, extensions, wallets, even build systems and more. Many like VPNs have logs sent elsewhere but deleted locally -- access to entire machine and all network access. People are way too trusting of "secure" systems/apps that are very common today based on trust. All of these apps/systems would pass code checks, reviews, security inspections and essentially be encrypted/"secure" though a copy is sent off to another area for review. At runtime the leak is in the direction of the data. Then you also have governmental oversight that opens up holes that can be exploited. On Ghost Users and Messaging Backdoors [2] > to add a “ghost user” (or in some cases, a “ghost device”) to an existing group chat or calling session. In systems where group membership can be modified by the provider infrastructure, this could mostly be done via changes to the server-side components of the provider’s system. > I say that it could mostly be done server-side, because there’s a wrinkle. Even if you modify the provider infrastructure to add unauthorized users to a conversation, most existing E2E systems do notify users when a new participant (or device) joins a conversation. Generally speaking, having a stranger wander into your conversation is a great way to notify criminals that the game’s afoot or what have you, so you’ll absolutely want to block this warning. > While the GCHQ proposal doesn’t go into great detail, it seems to follow that any workable proposal will require providers to suppress those warning messages at the target’s device. This means the proposal will also require changes to the client application as well as the server-side infrastructure. > (Certain apps like Signal are already somewhat hardened against these changes, because group chat setup is handled in an end-to-end encrypted/authenticated fashion by clients. This prevents the server from inserting new users without the collaboration of at least one group participant. At the moment, however, both WhatsApp and iMessage seem vulnerable to GCHQ’s proposed approach.) [1] https://www.vice.com/en/article/v7veg8/anom-app-source-code-operation-trojan-shield-an0m https://www.vice.com/en/article/v7veg8/anom-app-source-code-... [2] https://blog.cryptographyengineering.com/2018/12/17/on-ghost-users-and-messaging-backdoors/ https://blog.cryptographyengineering.com/2018/12/17/on-ghost...