Discussion with Mastodon developers

[lenoregilbert]

Hi there,

I've been working on E2EE implementation and specifically the Crypto Store on Android at this moment.

Would you mind having a conversation with us sooner rather than later?

Some of your assertions in the README.md are incorrect and there is also a lot of thinking (even for non-crypto experts) on how the different implementation approaches will result in different user experiences and I don't think it's possible for you to design a meaningful implementation without at least some discussion regarding our roadmap and UX goals for the feature.

Additionally, we are not intending to generate/distribute keys via the web server. We are implementing a local crypto store and currently generating those keys using libOlm. (matrix.io) There has been much discussion on the pros/cons of using the MegaOlm approach (Partial Forward Secrecy not ideal) vs Signal (a lot of keys and messages to send) vs WhatsApp (relayed via single primary device) especially when expressing it to the user as user-user messages (w/ group messages in the future) as opposed to device-device. Getting this into the web client will be another can of worms as it's unclear how we should establish a secure local store for the keys in a browser session. (Hence focusing on the iOS/Android app first)

We have a discord server - I'd be happy to bring you up to speed but ultimately you really need to discuss this with Eugen and possibly the app developers like Griska.

[soatok]

Would you mind having a conversation with us sooner rather than later?

Honestly, no.

This GitHub repository encapsulates the kind of work I'd normally work on privately and then present as one package once it's gone through several rounds of internal/private editing before anyone sees it. It's an ugly rough draft and I don't want people being negatively influenced by early drafts.

I'm developing it publicly in the spirit of FOSS.

However, it's emphatically not ready for anyone to look at yet. I'll remove the notice in the README when I think these conversations should begin.

Some of your assertions in the README.md are incorrect

See: What I just wrote.

and there is also a lot of thinking (even for non-crypto experts) on how the different implementation approaches will result in different user experiences and I don't think it's possible for you to design a meaningful implementation without at least some discussion regarding our roadmap and UX goals for the feature.

If you have literature on that available, I'm happy to review it. It would be useful to link to it here.

I don't want to start a conversation until I've convinced myself that E2EE is possible in a federated system.

Additionally, we are not intending to generate/distribute keys via the web server.

Good move.

We are implementing a local crypto store and currently generating those keys using libOlm. (matrix.io) There has been much discussion on the pros/cons of using the MegaOlm approach (Partial Forward Secrecy not ideal) vs Signal (a lot of keys and messages to send) vs WhatsApp (relayed via single primary device) especially when expressing it to the user as user-user messages (w/ group messages in the future) as opposed to device-device.

Please wait until I have time to define the key management story. You will likely find that my proposal addresses your needs without any of the mistakes of Megolm.

Getting this into the web client will be another can of worms as it's unclear how we should establish a secure local store for the keys in a browser session. (Hence focusing on the iOS/Android app first)

Please see: https://github.com/soatok/mastodon-e2ee-specification/blob/main/components/client-side-key-management.md#threat-5-the-web-server--javascript-cryptography

Even if you can keep secrets away from malicious instances, you can't keep the messages away, unless you use a browser extension instead of trusting the web browser.

[lenoregilbert]

Thanks for the quick reply - I'll keep an eye out for the Key Management Story, I've been trying to follow the patterns/implementations of Matrix & Signal but I'm open to other suggestions as well. (FWIW while we are currently using libOlm for the Ed25519 and other encryption primitives we are not using MegaOlm due to the lack of PFS and because we didn't get as far as group-level messaging yet)

Regarding the browser side key management - I think we are in agreement. I was learning towards a desktop app or device relay instead of a browser extension but no strong plans either way as we were focused on getting this right in the mobile apps first.