Securejoin v3: 4-step protocol with symmetric encryption

[Hocuri]

Motivation

• Today, the first message sent in the Securejoin protocol is sent unencrypted. This leaks the joiner's cryptographic identity to the server operator. Also, it needs special handling in chatmail servers, which otherwise only allow encrypted messages. Securejoin v3 will solve all these problems.
• Today, we need to send two tokens in the QR code (invite and auth). With securejoin v3, we will only need one token.

Flowchart describing the new protocol

As an image

In text form

 Alice                  ---- QR code with symmetric secret  --->                         Bob
   |                                                                                      |
   |    <-- vc-request (symm-encrypted, no info at all except for Bob's email address) -- |
   |                                                                                      |
   | -- vc-pubkey-required (symm-encrypted, contains Alice's pubkey) -->                  |
   |    (an attacker who has Alice's QR code can anyways see her cryptographic            |
   |    identitiy, so, it's not a problem to put the pubkey here)                         |
   |                                                                                      |
   |  <-- vc-request-with-pubkey (asymm-encrypted, contains Bob's pubkey, name&avatar) -- |
   |                                                                                      |
   | -- vc-member-added (asymm-encrypted, contains broadcast secret, name&avatar) -->     |

Click to see a comparison with alternative protocols

Rationale

• Since we can't do anything asymmetric in the first message from Bob to Alice, it has to be encrypted symmetrically.
  • Since this means that a server operator who has the AUTH token (by scraping the web for public QR codes) can decrypt this message, this message can't contain Bob's display name or avatar. We also don't want to leak Bob's cryptographic identity, so we also don't include Bob's public key (an alternative here would be to create a new keypair Bob-temp, which is what the 3-step protocol does, but this just adds unnecessary complexity).
• Since we want to give Alice the opportunity to review join requests (as a future improvement that doesn't require breaking the protocol), Alice can't send any private data in the second message.
  • So, she only sends her pubkey in the second message. Since Alice's fingerprint is in the QR code, a server operator who scraped her QR code from the web will also know the pubkey; this means that we can safely send the pubkey without potentially leaking any private data.
  • If we want to protect Alice's cryptographic identity from someone who sees her QR code, then this can be a future improvement (Alice can just create a new keypair Alice-temp for this) but is out of scope for now.
• In the third message, Bob can send his pubkey, avatar and displayname.
• In the fourth message, Alice can send her avatar, displayname, and broadcast invitation.

About the complexity "Alice needs to create a Bob-contact without knowing his fingerprint": It should be possible for Alice to receive and answer the first message without any database changes. This will probably mean that create_send_msg_jobs() and MimeFactory::from_msg() is not used, with some parts which are needed extracted into a separate function. I still have to check whether it makes sense to use MimeFactory::render().

Required security properties

Security properties we want:

• No MitM possible (assuming the server operator can't modify the QR code)
• No metadata sent in cleartext

Security properties we probably want:

• Even if the server operator sees the QR code, they can't find profile data
• Even if the server operator sees the QR code, they can't find Bob's key-fingerprint
• Possible to switch to quantumn-resistant cryptography (which means that we can't just put the pubkey or the first part of a DH exchange into the QR code, bc quantumn-resistant cyphers are long)

Other possibly-interesting security properties:

• Quantumn-resistant, assuming the channel operator can't see the QR code (we can simply encrypt everything sensitive with the AUTH token for this)
• We can let Alice review Bob's request before answering to the silent SMS (this requires profile data in the first message, though, so it's probably incompatible with other security goals)

Security properties we don't need to talk about right now:

• Even if the server operator sees the QR code, they can't see Alice's key-fingerprint (this will require an Alice-temp fingerprint, which is independent of which protocol we choose)

Keep in mind while implementing:

• There currently is this small bug:

    // TODO: There is a known bug in `observe_securejoin_on_other_device()`:
    // When Bob joins a group or broadcast with his first device,
    // then a chat with Alice will pop up on his second device.
  

Open questions

• [ ] How do we ensure backwards compatibility, and which amount of breakage is acceptable?

For reference, this is a follow-up to that comment: https://github.com/chatmail/core/pull/7042#issuecomment-3307348125

[adbenitez]

• Today, we need to send two tokens in the QR code (invite and auth). With securejoin v3, we will only need one token.

if this means users can't retract/reset invite links this will be really unfortunate

[Hocuri]

I's just one token instead of two, you can still retract it

[iequidoo]

| -- vc-pubkey-required (symm-encrypted, contains Alice's pubkey) --> | | (an attacker who has Alice's QR code can anyways see her cryptographic | | identitiy, so, it's not a problem to put the pubkey here) |

This means that even if Alice doesn't approve the join request, she now may be spammed with encrypted messages by Bob. But apparently this isn't easy to avoid.

| <-- vc-request-with-pubkey (symm-encrypted, contains Bob's pubkey, name & avatar)-- | | | | -- vc-member-added (symm-encrypted, contains broadcast secret, name & avatar)--> |

If these are symmetrically encrypted with the same AUTH token, a server operator who scraped the QR code from the web can see the names and avatars. E.g. one of the joiners can be a server operator, in this case multi-use QR codes aren't safe. Why can't we encrypt these messages asymmetrically? Both sides already know each other's pubkeys.

[Hocuri]

If these are symmetrically encrypted with the same AUTH token, a server operator who scraped the QR code from the web can see the names and avatars.

It was a typo, I edited my post. They should be asymm-encrypted