Meta: Encrypted state

[andybalaam]

@kaylendog will be working on encrypted state - we will track our plans and progress here.

Goal

Investigate the feasibility of MSC3414 and prototype it in rust-sdk.

Context

Currently, all state events in a room are unencrypted: only non-state events can be encrypted.

To enhance privacy, we should encrypt state events where possible.

Problems

• The server holds the current state of a room, and it uses type+state_key as the key of the map. This causes 2 problems:
  1. Encrypted events have a fixed type of m.room.encrypted so events of different types will clash
  2. We potentially want the true state_key to be inaccessible to people without decryption keys

We will start by not considering this problem, then progressively enhance our solution.

Plan

• Set-up, logins, passwords etc.
• Build matrix-rust-sdk including multiverse
• Run a local synapse and connect to it from multiverse
• Encrypt a test event. Write the minimum possible code to get a state event to send and receive whose contents are encrypted. Look at OlmMachine::encrypt_room_event. You will probably need to write a similar method called encrypt_state_event and figure out how to call it from multiverse. You will probably need to add code to decrypt state events if they arrive encrypted.
• Consider stuffing the event type into state_key so the server can hold two events of different type with the same state_key even if they are encrypted. E.g. change the state_key to be "{type}:${state_key}" (note: careful choice of separator will eventually be needed, but no need to worry too much now). Confirm that the server correctly returns the right state in this circumstance. Figure out how to get the client to "unstuff" it and understand the right type and state_key.
• Investigate how well this works. E.g. can I do live location sharing using encrypted state events?
• Implement runtime feature flag for encrypted state
• Merge into upstream SDK
• Investigate implementing encrypted state into existing clients - feature/labs flag.
• Implement encrypted state in Element Web as a labs flag.

Later Steps

• Evaluate using a new encryption algorithm vs the proposed encrypt_state_events field on m.room.encryption vs differentiating encrypted and cleartext event payloads in Ruma;
• Determine exactly which event types need encryption;
• Decide on state key handling - plaintext, string packing, HMAC obfuscated;
• How should invites be handled - key sharing even if history invisible? Session rotation;
• Spaces - implement a new m.space.child_info encrypted event, contains room name and topic;
• Room directory - exclude rooms with encrypted state?
• Explore partial encryption for critical events.

[kaylendog]

Accidentally closed - my bad!

[kaylendog]

Collating my thoughts for today (17/09/25) here:

Encryption Algorithms

• It doesn't make a lot of sense to me to introduce a new algorithm specifically for state events. My current implemetation uses the underlying Megolm algorithm, and I believe this will probably be the case regardless of how we choose to proceed. This could change depending on how we approach state keys; we will probably want to declare what method we are using to obfuscate HMAC keys.

• It would be possible to add an Encrypted variant to StateEvent, but Ruma relies quite heavily on macros to generate its types, and adding this variant has immediate far-reaching implications on the crate that aren't easy to resolve. I think if we take this route, it would probably be worth:

  • Introducing variants for Encrypted events to all of MessageLikeEvent, SyncMessageLikeEvent and StateEvent;
  • Introducing an EncryptedContent marker trait, analagous to RedactContent although without encryption ability, and all of the subsequent Encrypted(Sync)?{MessageLike, State}EventContent traits that will be needed to make that work.
  • Use a little deserialisaiton helper to catch the existence of an algorithm field in event content.

  This is all a bit tricky though, since we're now asserting all events can be encrypted, which wouldn't be true under this scheme anyway (see next section).

State Key Handling

• Plaintext has the obvious downside of being visible to the server - perhaps we should just enforce the idea that sensitive information should not be placed in the state key.
• String packing was trivial to implement, but it's a little awkward and probably won't pass a respec.

HMAC-obfuscated seems fine, but I think there are a few issues:

• Where do we get the key? We could tie it to the current session key but what happens when the session key gets rotated? This breaks the mapping from the server's POV, since HMAC_K(M) =/= HMAC_K'(M). We could recompute all the state keys for historical events on a session rotation, and kindly ask the server to forget all the old ones, but that would be a vast amount of compute for large rooms.
• So we would probably need a single key for the entirety of the room's existence, which kinda defeats the point?
• How would this key be shared? Not all rooms support history sharing/have it enabled, but we still need to be able to decrypt state. A dedicated key sharing process just for this key?

I think at the end of the day, there's no way to have the contents of the state key, and hence the cleartext event type and state key to be held securely by the server in a way that still preserves the (type, state_key) -> event mapping. I suppose it's an extra barrier, even if its a mediocre one?

Invites

This seems a bit tricky, I see a few ways to do this:

• Have the inviter use cleartext events in invite_room_state;
• Send the relevant key(s) that allows the invitee to decrypt the state held in invite_room_state over to-device messages, potentially ignoring history sharing;
• Introduce some form of selective decryption that allows keys to be "scoped", then give the invitee the key(s) that can decrypt the state held in invite_room_state. This seems cool, it's a little similar to what MSC4100 is proposing for signing keys. Doing this properly, where we can send a key with arbitrary scope starts to sound a lot like what MLS does, which is fun.

[kaylendog]

Tracked in spec proposal here: matrix-org/matrix-spec-proposals#4362

[andybalaam]

To close this we will chase through element-hq/element-web#30981 and then element-hq/element-web#30877