Independent public audit of Vodozemac, a native Rust reference implementation of Matrix end-to-end encryption

2022-05-16 — General — Matthew Hodgson

Hi all,

It’s been quite a while since our last independent E2EE review, and so we’re incredibly proud to present an entirely new independent security audit of vodozemac, our next generation native Rust implementation of Matrix’s Olm and Megolm E2EE protocols. The audit has been conducted by Least Authority, who specialise in comprehensive audits of security-sensitive decentralized technologies - and we are very grateful to gematik, who kindly shared the costs of funding the audit as part of their commitment to Matrix for healthcare in Germany.

This audit was a bit of a whirlwind, as while we were clearly overdue an audit of Matrix’s E2EE implementations, we decided quite late in the day to focus on bringing vodozemac to auditable production quality rather than simply doing a refresh of the original libolm audit. However, we got there in time, thanks to a monumental sprint from Damir and Denis over Christmas. The reason we went this route is that vodozemac is an enormous step change forwards in quality over libolm, and vodozemac is now the reference Matrix E2EE implementation going forward. Just as libolm went live with NCC’s security review back in 2016, similarly we’re kicking off the first stable release of vodozemac today with Least Authority’s audit. In fact, vodozemac just shipped as the default E2EE library in matrix-rust-sdk 0.5, released at the end of last week!

The main advantages of vodozemac over libolm include:

Native Rust - type, memory and thread safety is preserved both internally, and within the context of larger Rust programs (such as those building on matrix-rust-sdk). This is particularly important given the memory bugs which libolm sprouted, despite our best efforts to the contrary.
Performance - vodozemac benchmarks roughly 5-6x faster than libolm on typical hardware
Better primitives - vodozemac is built on the best practice cryptographic primitives from the Rust community, rather than the generic Brad Conte primitives used by libolm.

Also, we’ve finally fixed one of the biggest problems with libolm - which was that the hardest bit of implementing E2EE in Matrix wasn’t necessarily the encryption protocol implementation itself, but how you glue it into your Matrix client’s SDK. It turns out ~80% of the code and complexity needed to securely implement encryption ends up being in the SDK rather than the Olm implementation - and each client SDK ended up implementing its own independent state machine and glue for E2EE, leading to a needlessly large attack & bug surface.

To address this problem, vodozemac is designed to plug into matrix-sdk-crypto - an SDK-independent Rust library which abstracts away the complexities and risks of implementing E2EE, designed to plug into existing SDKs in any language. For instance, Element Android already supports delegating its encryption to matrix-sdk-crypto; Element iOS got this working too last week, and we’re hard at work adding it to Element Web too. (This set of projects is codenamed Element R). Meanwhile, Element X (the project to switch Element iOS and Element Android to use matrix-rust-sdk entirely) obviously benefits from it too, as matrix-rust-sdk now leans on matrix-sdk-crypto for its encryption.

Therefore we highly recommend that developers using libolm migrate over to vodozemac - ideally by switching to matrix-sdk-crypto as a way of managing the interface between Matrix and the E2EE implementation. Vodozemac does also provides a similar API to libolm with bindings for JS and Python (and C++ in progress) if you want to link directly against it - e.g. if you’re using libolm for something other than Matrix, for example XMPP, ActivityPub or Jitsi. We’ll continue to support and maintain libolm for now though, at least until the majority of folks have switched to vodozemac.

In terms of the audit itself - we recommend reading it yourself, but the main takeaway is that Least Authority identified 10 valid concerns, of which we addressed 8 during the audit process. The remaining two are valid but lower priority, and we’ll fix them as part of our maintenance backlog. All the issues identified are excellent valid points, and we’re very glad that Least Authority have added huge value here by highlighting some subtle gotchas which we’d missed. (If you write Rust, you’ll particularly want to check out their zeroisation comments).

So: exciting times! Vodozemac should be landing in a Matrix client near you in the near future - we’ll yell about it loudly once Element switches over. In the meantime, if you have any questions, please head over to #e2ee:matrix.org.

Thanks again to gematik for helping fund the audit, and to Least Authority for doing an excellent job - and being patient and accommodating beyond the call of duty when we suddenly switched the scope from libolm to vodozemac at the last minute ;)

Next up: we’re going to get the Rust matrix-sdk-crypto independently audited (once this burndown is complete) so that everyone using the matrix-sdk-crypto state machine for Matrix E2EE can have some independent reassurance too - a huge step forward from the wild west of E2EE SDK implementations today!

– Matthew

This Week in Matrix 2022-05-13

2022-05-13 — This Week in Matrix — Thib

Matrix Live 🎙

Dept of Spec 📜

Andrew Morgan (anoa) says

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals.
MSC Status
New MSCs:
[WIP] MSC3815: 3D Worlds
[WIP] MSC3814: Dehydrated devices with SSSS
MSC3813: Obfuscated events
MSCs with Proposed Final Comment Period:
No MSCs had final comment period proposed this week.
MSCs in Final Comment Period:
MSC3787: Allowing knocks to restricted rooms (merge)
Merged MSCs:
No MSCs were closed this week.
Closed MSCs:
MSC3790: Register Clients
Spec Updates
The Spec Core Team has decided to not include MSC3440 (threading via m.thread relations) specifically in the upcoming Matrix v1.3 release. We previously stated that it would be in v1.3, but there's a few unproven MSCs (namely MSC3773 (notifications for threads)) which make it feel improper to put threads into the spec at this stage. We're aiming for a future (very near) spec release to contain threads, assuming we can get enough of the feature landed. This is a very similar approach to what we did with Spaces: while the core feature existed as FCP-concluded for a while, we wanted to give some other MSCs a chance to land before writing it up formally.
As a follow-on from this, any implementations that are currently assuming "v1.3" spec support translates to threading support should note the following:
Clients which are pre-emptively checking for v1.3 in /versions should stop doing that. Look for org.matrix.msc3440.stable as an "unstable" feature flag instead.
Servers which offer MSC3440's behaviour should expose it on stable endpoints and expose org.matrix.msc3440.stable for clients to detect.
Optionally, clients and servers can drop support for the org.matrix.msc3440 (truly unstable) flag, given clients & servers should have already upgraded.
At the spec level, we'll still be writing up MSC3440's dependencies (aggregations and friends), but will notably be missing MSC3440 specifically in v1.3. If folks can update their clients urgently, it would be massively appreciated!
Random MSC of the Week
The random MSC of the week is... MSC2596: Proposal to always allow rescinding invites!
A simple change to the auth rules to help prevent an edge case where one is able to invite a user, but not disinvite them as the latter requires a separate permission. The MSC attempts to solve this by always allowing the cancellation of invitations you've sent.
A small MSC, but one with some open threads still. Perhaps a good opportunity to go in and clean it up!

Dept of Servers 🏢

Synapse (website)

Synapse is a Matrix homeserver implementation developed by the matrix.org core team

squah says

Hello everyone. This week the team cut a release candidate for Synapse v1.59, which includes:
New module API support for editing push rules.
Experimental support for MSC3266, federated room summary and MSC3786.
Updates to support for MSC2285, hidden read receipts.
Many bug fixes and internal improvements!
Meanwhile, the core team has looking at caches and memory usage: Erik has been looking at ways to reduce the memory usage of small servers, Shay's been adding some exciting new config options to limit the total memory usage of Synapse and David's added the ability to reload the cache factors of a running Synapse instance via SIGHUP.
In parallel, Olivier's been doing groundwork to reduce replication traffic for workerised Synapse deployments, Andrew (anoa) has been looking at media retention policies and work continues on faster room joins.

Dendrite (website)

Second generation Matrix homeserver

neilalexander reports

This week we've actually made two releases — Dendrite 0.8.4 and Dendrite 0.8.5 — which are both primarily targeting performance and bug fixes.
We've also released our new living documentation, which is available at https://matrix-org.github.io/dendrite/, which features new installation instructions and documents that will be helpful to Dendrite server administrators. We will be writing more documentation and expanding this over time.
Changes include:
The built-in NATS Server has been updated to version 2.8.2
Monolith deployments will no longer panic at startup if given a config file that does not include the internal_api and external_api options
State resolution v2 now correctly identifies other events related to power events, which should fix some event auth issues
The latest events updater will no longer implicitly trust the new forward extremities when calculating the current room state, which may help to avoid some state resets
The one-time key count is now correctly returned in /sync even if the request otherwise timed out, which should reduce the chance that unnecessary one-time keys will be uploaded by clients
The create-account tool should now work properly when the database is configured using the global connection pool
Fixes a regression introduced in the previous version where appservices, push and phone-home statistics would not work over plain HTTP
Adds missing indexes to the sync API output events table, which should significantly improve /sync performance and reduce database CPU usage
Building Dendrite with the bimg thumbnailer should now work again (contributed by database64128)
As always, feel free to join us in #dendrite:matrix.org for more Dendrite-related discussion.

Dept of Bridges 🌉

matrix-appservice-kakaotalk (website)

A Matrix-KakaoTalk puppeting bridge.

Fair reports

Most of this week's fixes are in the testing branch, so try it out!
Ability to DM your own KakaoTalk puppet
Fix to the problem of needing to DM a puppet twice to start chatting with them
Fixes to leaving KakaoTalk chats from Matrix (via the !kt leave bot command)
Nicer output of the whoami command, to make it easier to click on your own KakaoTalk puppet to DM it
Coming soon:
Proper support for setting an Open Chat title & topic from Matrix
Support for joining KakaoTalk rooms from Matrix, either by joining an existing portal or providing an Open Chat URL to the bot with a join command
Discussion: #matrix-appservice-kakaotalk:miscworks.net
Testing room: #kakaotalk-bridge-testing:miscworks.net / https://open.kakao.com/o/gjGQFuae
Issue page: https://src.miscworks.net/fair/matrix-appservice-kakaotalk/issues

Dept of Clients 📱

Ement.el (website)

Matrix client for Emacs

alphapapa announces

Ement.el, a Matrix client for [GNU Emacs](https://www.gnu.org/software/emacs], received some more updates this week:
Additions
New Transient-based command menu for room buffers, bound to ?.
New command ement-list-members, which lists all members in a room.
Member completion now completes from all members in a room (rather than only those whose messages have been seen).
Power-level events are displayed.
Grouped membership events have tooltips showing each member's individual event.
When usernames are colorized, message bodies may optionally be colorized in a less intense shade of the same color, so they are easily distinguished yet easy on the eyes (and, of course, the shading is customizeable).
Changes
When displaying usernames in the margin, names that are wider than the margin are abbreviated, with the full name in the tooltip.
Fixes
Typing notifications (recently broken--oops!).
Sending direct messages marks new direct rooms as direct rooms.
Event notifications for rooms not displayed in a buffer.
As always, feel free to join us in #ement.el:matrix.org.

Element (website)

Everything related to Element but not strictly bound to a client

Danielle announces

Hello and welcome to another Element TWIM!
Threads
We’re still hard at work improving the Threads Beta experience for y’all. Starting with Notifications and UI polish.
We’ve fixed some visual bugs on all of our platforms this week
We’re continuing work on MSCs for improvements to read receipts, push rules, and thread notifications in general.
Community testing
Next week, we are planning to test:
Video rooms
And the new release candidate
We have a new consent form for testers to fill in! For more info on our next testing sessions (sync or async), you can join us at #element-community-testing:matrix.org!

Element Web/Desktop (website)

Secure and independent communication, connected via Matrix. Come talk with us in #element-web:matrix.org!

Danielle reports

We’ve improved how messages are deleted, along with other defects. Some of our favourite improvements include:
Fixed room history visibility when you have keys to decrypt messages
Improvements to viewing long room topics
A number of UI tweaks and polishes including improved layout to the settings
Fix the way pills look
The team is actively moving tests to Cypress; You can find the latest test runs here

In labs (you can enable labs features in settings on develop.element.io or on Nightly):
Video Rooms! Turn them on and try them out, we’re continuing to squash bugs
We added a “copy link” option to the context menu
Removed some of the older features from labs
Improved ordering in the new search dialog

Element iOS (website)

Secure and independent communication for iOS, connected via Matrix. Come talk with us in #element-ios:matrix.org!

Ștefan says

The newest version of the app (1.8.14) was released on Monday! In this release we’ve made a bunch of improvements and bug fixes, check it out here
💊 We also merged an initial version of mention pills and are working on ironing out edge cases. Exciting!
There’s good progress on the new authentication flows and live location sharing, both of which we’re looking forward to sharing and testing with you soon.
On the ElementX front we're nearly done with the DevX setup and are working towards using the latest Rust SDK
unit and UI test runs on the CI and Codecov.io coverage reports
swiftlint, danger-swift and sonarcloud.io checks for code quality
automatic generation of PR builds, published on diawi
scripts for importing and reusing localizable strings from Android
towncrier changelogs and more

Element Android (website)

Secure and independent communication for Android, connected via Matrix. Come talk with us in #element-android:matrix.org!

Danielle reports

We’ve been working on smashing bugs, improving stability, and reducing crashes.
Our first time user flow is progressing - we’re starting to test the new authentication flow internally and will be asking for help testing this soon.

Cinny (website)

Cinny is a Matrix client focused on simplicity, elegance and security

ajbura says

Cinny v2.0.0: Session verification and other e2ee features
Features
Redesign app/user settings
Add support to manage cross-signing and key backup
Add support to manage sessions
Add Session verification by emojis
Add recently used section to emoji board
Add LaTeX / math input and rendering support
Add notification sounds
Add sound on incoming invites
Sort DM's by activity
Sort search results by activity
Improve jump to unread button
Replace confirm and prompt with custom dialogs
Adapt to different device widths
Native application using Tauri
Bugs
Fix loading on older browsers
Fix crash on load and room creation on dendrite
Fix can't open spaces from public room list
Fix max power level in room permissions
Fix incorrect custom html crashing app
Fix crash on unable to getContent of tombstoned room
Don't enable e2ee for bridged platform
See release at: https://github.com/ajbura/cinny/releases/tag/v2.0.0
Cinny for desktop
Since this release, we are also shipping a desktop app of Cinny for Windows, MacOS and Linux. You can download the app for your platform from https://github.com/cinnyapp/cinny-desktop/releases
Find more about Cinny at https://cinny.in/ Join our channel at: #cinny:matrix.org Github: https://github.com/ajbura/cinny Twitter: https://twitter.com/@cinnyapp

Dept of SDKs and Frameworks 🧰

matrix-rust-sdk (website)

Matrix Client-Server SDK for Rust

ben reports

The Rust Matrix team is very excited to announce the next major release Matrix SDK 0.5 "stores and native crypto", now available for everyone by adding matrix-sdk = "0.5.0" to their dependencies in their Cargo.toml. This first major release in about 8 months brings significant changes many have been waiting for:
Better, safer, native-er crypto: matrix-sdk 0.5 ditches libolm in favor of Vodozemac, the completely fresh rust-native re-implementation of the crypto crate. It has also been audited, the report of which is scheduled to be released soon.
Store revamp: the entire cache storage infrastructure for crypto and state has been restructured to allow for full plug-ability, with even the two default supported backends, sled and indexeddb both being separate crates now. And as a matter of fact, a community-driven sql implementation has already been published as beta (with postgres and sqlite support) by charlotte 🦝.
WebAssembly; both of these changes also allow us to finally make WASM a Tier 1 supported target for the SDK. Not only does it build and even use the browser native indexeddb for permanent storage, we also have CI tests ensuring nothing will break this support going forward.
Features, Features and Process: there's plenty more features and bug fixes in this release, e.g. native thumbnail generation support, as well as changes on our processes going forward.
For more details, check out the Release Notes.
Sidenote: If you want to contribute, or just learn Rust by actually doing it, we recommend taking a look team at the help wanted issues in our repo.

Dept of Ops 🛠

Buscarron (website)

Web forms (HTTP POST) to matrix

Aine announces

Buscarron v1.1.0 is here
Buscarron is the new backoffice of the etke.cc and its main feature is to receive web forms (HTML/HTTP POST) and convert them into (encrypted) matrix messages.
So, what's new?
Email confirmation after form submissions with Postmark
Templates support for redirect URLs
Automatically ban spammers, scanners and bots
Check out the source code and say hi in #buscarron:etke.cc

Dept of Bots 🤖

Who's In This Room Matrix Bot

Jake C says

If you use Matrix with the Signal bridge (or any bridge) with relay mode enabled, your guests have probably experienced the confusion where they don't know who else (on Matrix) is in the chat as only Matrix can double-puppet.
When this bot is added to a Matrix room, it will announce:
Who the room members are when a new Signal user joins;
When a Matrix user joins or leaves, who that Matrix user was.
I built it just this afternoon using the excellent matrix-bot-sdk, but it's in Typescript and has plentyful unit tests!
I don't currently have a public bot, but if anyone is interested please join #whos-in-this-room-bot-discussion:jakecopp.chat and say hello!
PRs for adding support for other chat apps (basically identifying which bridge from the puppeted username) are very welcome! https://github.com/jakecoppinger/whos-in-this-room-matrix-bot

Dept of Events and Talks 🗣️

J. Ryan Stinnett says

The videos from the HYTRADBOI conference a few weeks back are now publicly available, in case anyone was curious but couldn't make the conference. I gave a talk about building collaborative, open software on Matrix. The whole conference was great, so I recommend browsing the schedule for videos that may interest you. 😄

Dept of Interesting Projects 🛰️

uhoreg reports

Loomio, an open source collaborative decision making tool, now supports integrating with Matrix rooms using their chatbot. They previously supported other (lesser) chat systems, but have recently added support for Matrix.

Dept of Ping 🏓

Here we reveal, rank, and applaud the homeservers with the lowest ping, as measured by pingbot, a maubot that you can host on your own server.

#ping:maunium.net

Join #ping:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	envs.net	451
2	loang.net	576
3	jameskitt616.one	842.5
4	aria-net.org	857
5	jeroenhd.nl	892
6	mindlesstux.com	983
7	shortestpath.dev	1014
8	quyo.de	1345
9	matrix.nicfab.it	1571
10	halogen.city	1599

#ping-no-synapse:maunium.net

Join #ping-no-synapse:maunium.net to experience the fun live, and to find out how to add YOUR server to the game.

Rank	Hostname	Median MS
1	jameskitt616.one	171
2	loang.net	307
3	foxo.me	540
4	cry.is	763
5	kszczot.pl	777.5
6	dendrite.matrix.org	844.5
7	beckmeyer.us	851.5
8	dendrite.neilalexander.dev	1225.5
9	schuwi.science	1620
10	sspaeth.de	1978

That's all I know 🏁

See you next week, and be sure to stop by #twim:matrix.org with your updates!

This Week in Matrix 2022-05-06

2022-05-06 — This Week in Matrix — Thib

Matrix Live 🎙

Dept of Spec 📜

Andrew Morgan (anoa) reports

Here's your weekly spec update! The heart of Matrix is the specification - and this is modified by Matrix Spec Change (MSC) proposals. Learn more about how the process works at https://matrix.org/docs/spec/proposals.
MSC Status
New MSCs:
MSC3787: Allowing knocks to restricted rooms
MSC3786: Add a default push rule to ignore m.room.server_acl events
MSC3782: Matrix public key login spec
MSC3780: Knocking on action=join
MSC3779: "Owned" State Events
MSC3775: Markup Locations for Audiovisual Media
MSC3773: Notifications for threads
MSC3772: Push rule for mutually related events
MSC3771: Read receipts for threads
MSCs in Final Comment Period:
No MSCs are in FCP.
MSCs with proposed Final Comment Period:
MSC3787: Allowing knocks to restricted rooms
Merged MSCs:
No MSCs were merged this week.
"Wowza, that's a lot of new MSCs!" I hear you say. This is actually a listing of the last 3 weeks, as it was pointed out to me that the last 3 editions of TWIM have not all features an MSC status update - which means some MSCs may not have necessary made it into the limelight.
As such, here's those from this past week, as well as the ones that were missed!
Spec Updates
It's that time of the year again - a new Spec release is on the horizon! Matrix v1.3 is expected to land sometime this month, and will include:
MSC3440 (threads) + related MSCs
MSC3787 (knock+restricted join rules)
MSC3604 (room version 10)
Any other MSCs which have so far been accepted, but not yet made it into the spec.
MSCs which land between now and v1.3 might get incorporated if easy enough, though chances are they'll slip to v1.4 (expected next quarter).
On top of that, the other bit of news is that the proposal-in-review label has now been removed from the matrix-spec-proposals repo and thus all MSCs. This doesn't mean your MSC is no longer in review! We simply found the label redundant along with the other labels in the process (it was attached to all MSCs which hadn't been accepted/merged yet, which means very little) and thus we decided to remove it to reduce noise.
Random MSC of the Week
The random MSC of the week is... MSC2881: Message Attachments!
This MSC has actually been potentially(?) superseded by MSC3382. In short, both look to provide a solution to the problem of attaching (multiple!) images to messages, such that clients can display an album of images in a single event in the timeline.
Check it out if you're interested in introducing such a feature!