soatok
commented
1 year ago 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)
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
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.