GSoC'20 Final Report - Matrix.org

- CH Chethan Reddy

Organization : matrix.org

Project : Adding Features in End-to-End encryption for Nheko-Reborn

My main work can broadly be classified into adding two main features to end-to-end encryption, viz. Device Verification and Cross Signing, and for implementing these I had to work on two repos Nheko (main client) and mtxclient (a C++ Library which implements the Client-Server API related to matrix network).

For the frontend, Qt C++ Framework was used for GUI and the backend was written in C++17.

General Overview 👓

Device-Verification enables two devices to construct a trust between them. In matrix network, every device of the client is uniquely identified and has to be verified individually to ensure the encrypted messages are exchanged among the trusted devices only. In this project the Device-Verification has been done using SAS verification method.

Cross-Signing is a feature which enables a user to trust multiple devices of same user using an already verified device (which would create a trust between these two users) . It avoids the hassle of verification of multiple devices of same user individually. In the project the user-verification has been done both by room verification and to-device verification. A feature to display the list of verified devices in the User-Profile is also implemented by going through the trust chain.

Code ⌨️

This is the list of PRs made to nheko and mtxclient

nheko

Fix Nheko build (Merged)

Device-Verification and Cross-Signing (To be Merged)

mtxclient

Fix issue in the build of device_verification branch (Merged)

Add methods for SAS (Merged)

Room verification and cross-signing (Merged)

As some of PRs are huge, I have divided each PR into major commits of sub-tasks and it is mentioned in the "Outcome" of the project given below

Outcome of the Project 🔨

Re-Implemented UserProfile in qml which allows user to start verification (1, 2, 3, 4)
Fixed bugs in the mtxclient which caused mtxclient not to build (#27)
Made Changes to send_to_device message API in mtxclient and made corresponding changes needed in Nheko (#198)
Added and Modified Key-Verification Related Structs as per the latest spec which works for to-device and room-message verification (1 , 2)
Added serializing required for Key-Verification Structs (#37)
Implemented device-verification with to_device messages with both key.verification.start and key.verification.request (1, 2, 3, 4, 5)
Integrated SAS part of Olm-library to the mtxclient to create a SAS struct which has APIs for (#32)

Creating ed25519 key-pair needed for verification
Calculate the numbers or emojis based on private key and other user's public key
Verify the mac sent through key.verification.mac

Implemented part of the Cache which (1, 2)

Stores the status of verified device (device-verified and cross-verified) and user verification status
Stores user keys and updates them as they become outdated

Added a wrapper API for query keys to fasten the process of querying keys with cache (1)
Added features in UserProfile to unverify and show blocked devices (1, 2)
Implemented Room Verification (1, 2, 3, 4)

Changing the structs in mtxclient
Changing the flow to adapt to any type of verification flow
Detecting and sending required signals in the timeline
Forming Verification Messages with proper relations

Checking and Verifying Users and their devices (1, #37)

Added mtxclient API to check signature of ed25519 keys with the help of Olm Library
Implemented the Trust Chain to check the status of other user's Verification and other user's trusted Devices

To-Do's 🗒

To implement SSSS key storage, thereby completing cross signing

Videos 🎬

The working of Room Verification and Device Verification has been shown in the following video links

Device-Verification
Room-Verification

The Videos also show the UserProfile and it's features. As can be seen in the video the verification status of the device changes after successful device-verification (yellow -> green). It may be noted that the verification status i.e. color of lock remains yellow for other devices even after Room Verification because the other user has not yet verified all of their devices. These devices will be trusted once the other user extends the trust chain to them.

Thank you! 🙏

I had a wonderful time working for Matrix from May this year. I'm grateful to be part of the Matrix community and had the pleasure of working with my mentors Nico and Red_Sky. The project not only provided me a great learning oppurtunity but also to realize the significance of the Open-Source. I'm looking forward contributing to the Matrix projects in the future and implement even more cool features. Thank you Matrix, Google, Nico and Red_Sky for making this summer a wonderful experience.