support zero-knowledge encryption for toots/DMs

[KiaraGrouwstra]

Pitch

The UI now warns us that:

Posts on Mastodon are not end-to-end encrypted. Do not share any sensitive information over Mastodon.

Would it be possible to use zero-knowledge encryption such that neither ISPs nor Mastodon servers could read a user's posts (whether toots or DMs), if not made public?

Disclaimer: I'm unsure what challenges federation adds here, including if this is even possible.

Related:

• Add end-to-end encryption API #13820
• OTR for direct messages #1093
• [feature request] make private messages zero knowledge #12128

Motivation

Now that Twitter has changed hands, interest in Mastodon seems on the rise.
It would be nice if we were to support encryption to the extent that users would feel safer on Mastodon.

[shleeable]

My understanding is they WANT to use crypto, but don't have anybody with the skills.. Do you know a good cryptographer who knows Ruby and mobile appdev?

[ClearlyClaire]

That was planned and we did make the server-side work (or at least some of it) as you've seen in #13820. But the client-side work is missing, not primarily because of the cryptographic aspect (although as always, implementing cryptography has to be done carefully), but because we haven't defined a protocol or a format for the contents of the encrypted messages: the server-to-server protocol is ActivityPub, and much could be reused for the encrypted messages as well, but this is not necessarily the best choice, and client apps typically do not handle ActivityPub itself but other representations simplified and produced by the server software. Of course, with encrypted messages, the server cannot do this processing, and any way we chose, the apps will have more work to do.

[KiaraGrouwstra]

i see, thanks for clarifying!
if the design (protocol/format) is the first challenge, could it help to split the cryptographic design from the implementation?
not that i'm in cryptographer circles, but perhaps if such a need could be boosted online by someone who is from such a circle...

[ClearlyClaire]

The cryptographic design side of things is done (though not implemented in any app, and both the design and eventual implementation could surely benefit from a review). What's missing is deciding and agreeing upon a format for the cleartext itself.

[C3n7ral051nt4g3ncy]

I don't see encryption as really fundamental for toots.
However, it would be nice to have E2EE (End-to-end Encryption) for DM's.

[nofunnyusernames]

This seems inherently difficult as mastodon is used as a website, or with many different apps. Where are the users supposed to store the keys for their encrypted DMs? Of course one could use the user's password to decrypt keys stored on the server inside the browser but since admins are capable of resetting users passwords that wouldn't bring any real additional security.

[skippernl]

Not in the crypto circle. Could we use something like pgp with a public key and a personal private key?

[z0noxz]

If E2EE is the only thing that's the goal, then simply publishing your public key with your fingerprint on your Mastodon profile and then letting people use it to encrypt messages to you is something that could be accomplished today -- without any further implementation in the Mastodon code base. It just works.

However, as stated earlier, the logistics of managing the private key is the problem. Is it stored outside of Mastodon -- forcing you to "manually" decrypting each message -- or is it stored on a Mastodon instance which kinda defeats the purpose of being "zero knowledge" or at least making it much more difficult, based on how the key is decrypted using a password (and by sending it to the instance).

By using public/private keys as an optional overlay makes this much simpler. Albeit, not necessarily what people is asking for.

Edit:
Of course, the decryption could be done client side using something like a javascript program, but this raises other security concerns instead.

[craftycorvid]

Most of these issues have been solved by zero-knowledge encryption email providers like Proton Mail.

You use the user's password to encrypt their private key. You store all a user's DMs encrypted at rest, and decrypt on the client side after login. If the user has to reset their password, they lose access to their encrypted DMs unless they can remember their old password (just the history of DMs. They still have access to the account, so they can send new DMs with a new public/private key). If a user changes their password you encrypt the private key with the new password.

The only real challenge is third party clients, those will have to implement support themselves.

[z0noxz]

The only issue that isn't resolved using client side decryption in a web browser (using something like a javascript program) -- and this is perhaps a discussion of a greater issue -- is the trust in proprietary third party browser plugins. Without insight into how these plugins work you will never be sure if they collect either the encryption key, the password or the message. Sure, you could block them from accessing specific sites depending on you browser. And given how common it is for users to install third party plugins in their web browser this can be a big issue for security. Of course the same can be said about proprietary operating systems in general, so it all comes down to the level of security you are after and the risks you are prepared to take (and hopefully aware of).

Maybe, I'm just overly pedantic.

[virtadpt]

@z0noxz The pubkey could be part of each account's metadata, which is used by other instances for follows anyway.

[z0noxz]

@virtadpt That sounds like a good idea for an implemented solution. The only risk I see, as stated earlier, is with the private key that has to be stored somewhere as well.

[bhack]

How it is implemented in the Matrix protocol as it has also web clients?

[z0noxz]

@bhack I'm not that well read on how Element is implementing decryption, and there are non-web based clients for the Matrix protocol as well (see https://matrix.org/clients-matrix/). But, to cite an answer from stack overflow (https://stackoverflow.com/a/4524652):

[...] yes, if the password [referring to the password of the private key] is strong enough this looks to be very secure (unless someone messes with the user's browser or computer, think keylogger or malicious firefox plugin or the site itself undermining the script).

The big question is whether you can trust the browser or not, when it comes to web clients.