[Tracking issue] End-to-End encrypted Broadcast Channels

[Hocuri]

Here I will collect all information around implementing broadcast channels, similar to the ones known from Telegram/WhatsApp. As oppsosed to Telegram/WhatsApp, channels will be end-to-end encrypted in Delta Chat. Some other features known from Telegram/WhatsApp will be missing.

Implementation

Show broadcast channels in their own, proper "Channel" chat

I checked all checkboxes which I implemented in a PR, even if it's not merged yet.

Core work (#6901):

• Add new chat type InBroadcastChannel and OutBroadcastChannel for incoming / outgoing channels, where the former is similar to a Mailinglist and the latter is similar to a Broadcast (which is removed)
  • Consideration for naming: InChannel/OutChannel (without "broadcast") would be shorter, but less greppable because we already have a lot of occurences of channel in the code. Consistently calling them BcChannel/bc_channel in the code would be both short and greppable, but a bit arcane when reading it at first. Opinions are welcome; if I hear none, I'll keep with BroadcastChannel.
• api: Add create_broadcast_channel(), deprecate create_broadcast_list() (or create_channel() / create_bc_channel() if we decide to switch)
  • Adjust code comments to match the new behavior.
• ASK Desktop developers what they use is_broadcast field for, and whether it should be true for both outgoing & incoming channels (or look it up myself)
  • I added is_out_broadcast_channel, and deprecated is_broadcast, for now
• When the user changes the broadcast channel name, immediately show this change on receiving devices
• Allow to change brodacast channel avatar, and immediately apply it on the receiving device
• Make it possible to block InBroadcastChannel
• Make it possible to set the avatar of an OutgoingChannel, and apply it on the receiving side
• DECIDE whether we still want to use the broadcast icon as the default icon or whether we want to use the letter-in-a-circle
  • We decided to use the letter-in-a-circle for now, because it's easier to implement, and I need to stay in the time plan
• chat.rs: Return an error if the user tries to modify a InBroadcastChannel
• Add automated regression tests
• Grep for broadcast and see whether there is any other work I need to do
• Bug: Don't show ~ in front of the sender's same in broadcast lists

UI work (deltachat/deltachat-android#3783):

• Rename "broadcast list" to "channel" or "broadcast channel" both in UI and code (depending on whether it's important to be concise in the particular place). There are new stock strings in which broadcast_list is replaced with channel
• Adapt to the new chat types InBroadcastChannel and OutBroadcastChannel for incoming / outgoing channels, where the former is similar to a Mailinglist and the latter is similar to a Broadcast (which was removed)
• Adapt to the new create_broadcast_channel() API

UI Testing:

• Creating a channel
• Adding/removing members from a channel
• Set a channel avatar, and check that receivers see it after sending a message
• Change the channel name, and check that receivers see it after sending a message
• On the receiving side of a channel, check that it's not possible to send a message
• On the receiving side of a channel, check that it's possible to block the chat
• On the sending side of a channel, check that it's possible to add and remove members, and that the shown texts are correct (e.g. "Remove X from Channel?" instead of "Remove X from Chat?")
• Both on the receiving and sending side of a channel:
  • In that chat, open the 3-dots menu, and check that things look fine
  • In the chat, check that the subtitle is correct
  • Open the profile page for a channel, and check that things look fine
  • Check that ephemeral messages actually disappear

Symmetrically encrypt broadcast channels

Channels need to be symmetrically encrypted, because if we encrypted them asymetrically, like we do for all other messages:

• with some technical expertise, it would be possible to find out who the other recipients are
• when there are a lot of recipients, the messages would be very big.

This will need a lot of work (like new QR codes) which I'll write about later.

• Talk to some PGP experts that the general idea is fine

[iequidoo]

• Consideration for naming

Maybe {In,Out}Broadcast? If we remove the current Broadcast lists, these don't conflict with anything. BroadcastChannel is quite long and will cause extra line wrapping. OTOH just Channel would be ambiguous.

• chat.rs: Return an error if the user tries to modify a ReadonlyChannel

I think it should be possible to rename incoming broadcast channels the same way it's possible for contacts. Btw, how is ReadonlyChannel different from an incoming one?

Channels need to be symmetrically encrypted

They can be asymmetrically encrypted, but the private key should be shared across contacts. Anyway, messages should be signed with the sender's key (before encryption is done). I don't suggest anything right now, but maybe asymmetric encryption fits better into PGP or at least the current code. Can you provide any reference where the symmetric encryption scheme is described?

[Hocuri]

Maybe {In,Out}Broadcast? If we remove the current Broadcast lists, these don't conflict with anything. BroadcastChannel is quite long and will cause extra line wrapping. OTOH just Channel would be ambiguous.

Not sure - then, the name in the code and the name in the UI don't have anything to do with each other. OTOH, it's true that BroadcastChannel is quite long

I think it should be possible to rename incoming broadcast channels the same way it's possible for contacts.

I would assume that this leads to user confusion, also since it's not possible to rename channels in other messengers. But anyways, in the first iteration I will try and keep things simple, which means leaving away non-essential features like renaming of incoming channels

Btw, how is ReadonlyChannel different from an incoming one?

Not at all, ReadonlyChannel is just another name which I used in a previous version of my TODO list. I renamed it now.

Can you provide any reference where the symmetric encryption scheme is described?

https://www.rfc-editor.org/rfc/rfc9580.html#seipd, encrypt_device_token() at https://github.com/chatmail/core/blob/main/src/push.rs#L76

[iequidoo]

Not sure - then, the name in the code and the name in the UI don't have anything to do with each other. OTOH, it's true that BroadcastChannel is quite long

"Bcast" is the common shortening for "broadcast". But IMO the most important thing is to have similar naming in the core and UI's code, how things are translated in the UI is secondary, maybe some languages don't have obvious translation for "broadcast" at all.

https://www.rfc-editor.org/rfc/rfc9580.html#seipd, encrypt_device_token() at https://github.com/chatmail/core/blob/main/src/push.rs#L76

Well, encrypt_device_token() encrypts to a public encryption subkey (i.e. asymmetrically) and doesn't sign the message. Would be nice to know how broadcast messages are authenticated, but if you'll write about that later, i can wait

[Hocuri]

I meant this:

    let mut msg = pgp::composed::MessageBuilder::from_bytes("", padded_device_token).seipd_v2(
        &mut rng,
        SymmetricKeyAlgorithm::AES128,
        AeadAlgorithm::Ocb,
        ChunkSize::C8KiB,
    );

And then, there is the function symm_encrypt():

        let mut rng = thread_rng();
        let s2k = StringToKey::new_default(&mut rng);
        let builder = MessageBuilder::from_bytes("", plain);
        let mut builder = builder.seipd_v1(&mut rng, SYMMETRIC_KEY_ALGORITHM);
        builder.encrypt_with_password(s2k, &passphrase)?;

        let encoded_msg = builder.to_armored_string(&mut rng, Default::default())?;

which actually symmetrically encrypts, but with seipd_v1, which is worse than seipd_v2 IIUC. So, I will probably do the same as symm_encrypt(), but using seipd_v2, but I will talk to a PGP expert first.

[iequidoo]

I guess using seipd_v2 with encryption to a password is possible, but note that the message must be signed with the sender's key first. Signing isn't needed in case of Autocrypt Setup Message because the password isn't shared. But my concerns are that overall such a scheme isn't standardized by OpenPGP and it would require more coding and more difficult audits while creation a shared asymmetric key (even w/o uid) is a bit more computationally expensive, but allows reusing the existing code. Also i'm not sure that with symmetric encryption broadcast messages won't be distinguishable from group messages for passive eavesdroppers.

EDIT: Took a look at the code, indeed, it looks possible to add another version of pk_encrypt() which uses seipd_v2() and encrypt_with_password() instead and that should be fine according to OpenPGP. As for protecting the message type (group/broadcast) from passive eavesdroppers, this doesn't look technically feasible anyway, particularly for large broadcast channels because we don't want the message size to grow with the number of recipients.