Adopt the E2EE cryptography module from matrix-rust-sdk: "Element R"

Context

Element Web currently uses a transpiled version of https://gitlab.matrix.org/matrix-org/olm originally written in C++

Using the rust-sdk’s WASM bindings, we replace our entire crypto implementation for performance, stability, security, and maintenance reasons. This project is already approved for work to begin.

The intent is to support both old & new crypto implementations side-by-side through a labs flag up until we’re ready to ship.

High level overview of approach

(as of December 2022)

• 1. Expose a config.json setting which will make the js-sdk use matrix-sdk-crypto-js instead of libolm. At this stage there will be no support for migrating existing sessions between libolm and rust.
• 2. Build up functionality based on the rust sdk:
  • basic encryption and decryption support
  • attachment/media support
  • Key backup
  • Cross signing
  • Key sharing … plus other things TBD.
• 3. Implement a one-way migration from libolm to rust, and allow people to opt into it via the labs flag.
• 4. Further work to achieve parity with the libolm implementation. (Matrix Content Scanner integration? Extensions etc for Element Call and widgets?)
• 5. Finish migration:
  • Enable the labs flag by default for new sessions
  • Forcibly migrate existing sessions to rust sdk
  • Get rid of the config flag and legacy code

After step 2, Element R web should be good enough to replace libolm-based Element Web as a daily driver. We’ll begin to encourage users to try out a hosted instance of it and give feedback, while continuing with step 3 and beyond.

Detailed plans from April 2022

Phases

Phasing is approximate and used as an estimation tool. This list will be updated often - check back frequently.

Time estimates are not guarantees or even accurate - they are relative. They will also be updated as needed.

Phase 1: Prove it works (1-2 months)

• [--] Bindings exist on NPM (in progress)
• [ 5] Introduce labs flag for js-sdk
• [13] Hook up rust stores to storage. Rudimentary one-way migration.
• [13] Hook up to sync loop, basic encryption and decryption support.
  • Including attachment/media support
• [ 8] Key backup (protocol level, not UI)
• [ 8] Key sharing (protocol level, not UI)
• [13] Cross-signing (protocol level, not UI)
• [21] Two-way migration for labs flag, allowing users to “switch” between implementations
  • Potential to implement this as an implementation which writes to both stores saving us from migration

Phase 2: Establish trust in the plan (1-2 months)

• [ 8] Benchmark old crypto & new crypto to establish performance targets
• [??] Tests which prove old crypto was working
  • “Working” is defined as behavioural traits, not necessarily bug-free.
• [??] Tests which prove the new crypto isn’t any more broken than old

Phase 3: Build a plausible client (2-4 months with questionable accuracy)

• [??] Self verification
• [??] Other user verification
• [??] Visual indicators for user trust (cross-signing, 4S)
• [??] UI bits for key backup, key sharing, and cross-signing
• [??] Manual key export
• [??] Historical key sharing (for room history)
• [??] Device management

Phase 4: Polish and remaining bits (1-2 months)

• [13] Support for customisation endpoints/modules as needed
• [13] Matrix Content Scanner integration (if needed)
• [??] Device dehydration
• [??] Functions required by Element Call and widgets (custom to-device messages?)
• [??] Posthog metrics
• [??] TBD stuff from https://github.com/matrix-org/matrix-rust-sdk/milestone/1
• [??] Get design involved for migration experience

Phase 5: Stability (1-2 months)

• [??] Enable by default on Nightly and Develop (not production, EMS, app, or staging)
• [??] Fix bugs & build comfort
• [??] Enable by default in production (EMS, app, and staging alongside existing develop channels)
• [??] Fix bugs & build comfort

Phase 6: Release (1 month)

• [??] Convert migration to a one-way migration
• [??] Remove old crypto code (keep migrator)
• [??] Remove labs flag
• [??] Eternal maintenance

[Hywan]

@novocaine Nothing I’m aware of except the one mentionned by @turt2live hereinabove.

[Hywan]

Here is the meta issue for matrix-sdk-crypto-js, https://github.com/matrix-org/matrix-rust-sdk/issues/1016