Bring encryption (E2EE) out of alpha

[qazip]

There was an issue missing for E2EE. I believef fully-featured E2EE clients is what is missing in the matrix-verse.

Do you plan to tackle E2EE @redsky17?

[dessalines]

Nheko is the only client outside of riot with e2ee support. I know its missing the key sharing, and also I get errors when I try to import room keys, but other than that it's already working.

[qazip]

It's not working for attachments, for example. There is still work to be done if one wants to use E2EE in nheko. As the README suggests, it is a "proof of concept".

[redsky17]

Full E2EE support is on the roadmap, but I'm not willing to commit to a timeline. There are a number of issues and features that nheko needs to bring it even close to feature parity with Riot and some of the other applications. Full E2EE support is probably the most involved of those, and needs serious focus due to the inherent privacy aspect involved.

[r3k2]

@redsky17 what if we cheap in money? IDK but there is nobody I know that will use matrix with out e2ee for anything other than software projects. In our point of view e2ee is prob the single most important feature.

[fadelkon]

I guess that this issue from mujx's nheko is still valid, right? mujx/nheko#358

Maybe chopping down some smaller issues would make it easier to grasp the size of the whole goal.

• Push matrix spec writers to define the import/export features
• Adapt the import/export to the specs
• Support encryption for attachments too.
• Device verification
• Own devices management

Something like this? do you want to open issues? I don't know the project internals and doubt my C++ skills are enough for something so sensible.

[redsky17]

So a lot of these things have already been taken care of in the 0.7.0 pre-release (I've checked the ones that are done off of your list). I'm currently working on device verification. Really the only thing that hasn't been addressed / started is the whole 'Own devices management' portion. I know device verification will be in the 0.7.0 release. Not sure about device management yet.

[deepbluev7]

Currently blocked by #70. Since that is reserved for GSoC (if we get a student for that), I've moved this to the backlog for now, so that we can unblock 0.7.0 for now, release that, and work on it after the release. Apart from that, some of the work for this is already done, so it should be feasible in the next few months (hopefully).

[deepbluev7]

Apart from verification, this needs some additional verification on to_device messages and I guess it should be able to recover from corrupted olm channels.

[opusforlife2]

@deepbluev7 Is this planned for any time soon? I feel very hesitant to use a client whose E2EE implementation isn't already declared stable, considering all my Matrix chats are encrypted by Element.

[deepbluev7]

We plan to do that for the next major release. There are just a few small issues left, that may be security sensitive. Otherwise the encryption should work, I just wouldn't say there are no ways an attacker can cause issues currently, if they control your homeserver. We need to do a full pass over the code once more and check for potential issues.

[opusforlife2]

Alright. Thanks for the update!

[KaiMartin]

Currently, while using nheko 0.8, I seem to be unable to verify sessions started on a different device. Unfortunately, this is a roadblock for my use case, which is using postmarketOS as a daily driver on a Motorola G4. Virtually all my matrix chats are encrypted and of course already started on other devices. Element is not an option because this application is not packaged for alpineos in the first place, which postmarket is based upon. Mirage fails with unrecoverable errors and is generally on the fat side for the computing power of the G4. Quaternion and fractal do not support encryption at all. So nheko seems to be the closest by quite a margin.

I assume, the inability to verify is one of the remaining issues mentioned above. Is his correct? Or did I miss something? If so, can you give a rough estimate when 0.9 may be relased? I would volunteer as an alpha tester of a self compiled version if verification is fixed in some development branch.

Thank you for tackling the encryption task!

---<)kaimartin(>---

[deepbluev7]

Verification worked fine for me on 0.8.2, so this may be specific to your setup? The missing part with Nheko is that it doesn't set up cross-signing, but I believe you did that already on a different client?

[deepbluev7]

So remaining todos that I want to tackle before stable:

• Online key backup
• "Request keys button" and in general showing the encryption status more nicely in the timeline
• Showing the verification status of a room
• SSSS and cross-signing bootstrapping
• Only generate device identity after first login (there are some bugs that might create a new identity later, breaking e2ee)
• Store megolm session index <-> event_id in cache to protect against replays
• Logout devices

[opusforlife2]

@deepbluev7 Congrats on the major release! You've still qualified E2EE as 'somewhat' stable. What's left to do here before it can be called 'confidently' stable?

[deepbluev7]

Test stuff and report bugs. :D

[deepbluev7]

I guess it is out of alpha though, so closing this.

[opusforlife2]

@deepbluev7 Thanks for confirming! How risky will testing be? Can bugs potentially corrupt the entire room or only those messages that Nheko sends?

[deepbluev7]

You might not be able to decrypt messages or in the worst case encrypt messages to the wrong set of people. It shouldn't cause any other issues.

[opusforlife2]

You might not be able to decrypt messages

That's okay. Since I can use Element to see those messages, there won't be any information loss.

encrypt messages to the wrong set of people

Could you clarify this a bit? Do you mean Nheko could send my message to the wrong user?

[deepbluev7]

Could you clarify this a bit? Do you mean Nheko could send my message to the wrong user?

If there is a bug in the End for "End to End Encryption", Nheko might track the wrong devices for a user or so. In that case the server could insert a malicious device and receive the messages or Nheko might send a message, that can be decrypted by a user, that was kicked. We don't know of any such cases so far, but any code can have bugs. The message is relayed by the server, so that can't be buggy on our end, but the server could be malicious and our protection against that could be buggy.

[opusforlife2]

So as long as the users' homeservers are fine (we're all doomed if matrix.org is actually malicious :P) then there is no issue, right?

[deepbluev7]

Sure, but then you don't need e2ee!