3 ms·

The problem I have with matrix is more that it’s a real pain to write your own client that supports E2EE and such

Macha 5y ago
Is it easier to write an xmpp client which supports E2EE?
Arnavion 5y ago
I've been writing my own client (for kicks) from scratch by just following the specs, including E2EE. I have to agree - the documentation is terrible. It's split between [1], [2] and [3] and probably many more, but [2] is "unstable" (see [4]) and [3] is informal (see [5]). All the docs are also full of broken intra-links, so I've been even afraid of having `// Ref: https://matrix.org/docs/ https://matrix.org/docs/...` comments in my code just because I expect they'll become broken some time later. The docs are often written from a JS perspective. For example, every mention of PBKDF2 talks about using "using SHA-512 for the hash function", but PBKDF2 uses a two-input PRF, usually an HMAC. What they mean is that it uses HMAC-SHA512, but I assume they keep saying "using SHA-512 for the hash function" because that's what the JS window.crypto.subtle API uses. [6] Also, God the keys, so many keys. Keys used to encrypt other keys used to encrypt other keys, with different kinds of encryption and formats each time... [1]: https://matrix.org/docs/spec/client_server/r0.6.1 https://matrix.org/docs/spec/client_server/r0.6.1 [2]: https://spec.matrix.org/unstable/client-server-api/ https://spec.matrix.org/unstable/client-server-api/ [3]: https://matrix.org/docs/guides/implementing-more-advanced-e-2-ee-features-such-as-cross-signing/ https://matrix.org/docs/guides/implementing-more-advanced-e-... [4]: AFAICT there is no stable version of [2]. [1] is not it; [1] and [2] have completely different content. Eg [2] explains how "m.secret_storage.key.<key_id>" events work, but this information is not present in [1]. [5]: As a concrete example, I've been working on deriving secret keys from passphrases for a few days, but it always derived the wrong key. I finally figured out why this morning - [3] implies the salt is base64-encoded but it's actually utf8-encoded, so I was decoding it incorrectly. [6]: https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Params#properties https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Param...
- miloignis 5y ago
  I believe that [1] is indeed the stable version of [2] - [2] contains things that [1] does not because it has new bits merged into it that have not yet been in a stable release. I think some of the confusion stems from them also swapping to a new version of the webpage in [2] that hasn't rolled out to the stable spec in [1] yet. Good warning on the JS stuff, I actually just started reading through the E2EE docs again to prep for my client, and I appreciate the heads up!
  - Arnavion 5y ago
    It is impossible to implement E2EE without the information in [2] that is not present in [1]. [2] is how you get access to the storage key that Element etc used to store encrypted secrets in your account data. So if anyone's goal is to build a Matrix client that's actually useful, [2] is unavoidable.

Is it easier to write an xmpp client which supports E2EE?

I've been writing my own client (for kicks) from scratch by just following the specs, including E2EE. I have to agree - the documentation is terrible. It's split between [1], [2] and [3] and probably many more, but [2] is "unstable" (see [4]) and [3] is informal (see [5]). All the docs are also full of broken intra-links, so I've been even afraid of having `// Ref: https://matrix.org/docs/ https://matrix.org/docs/...` comments in my code just because I expect they'll become broken some time later. The docs are often written from a JS perspective. For example, every mention of PBKDF2 talks about using "using SHA-512 for the hash function", but PBKDF2 uses a two-input PRF, usually an HMAC. What they mean is that it uses HMAC-SHA512, but I assume they keep saying "using SHA-512 for the hash function" because that's what the JS window.crypto.subtle API uses. [6] Also, God the keys, so many keys. Keys used to encrypt other keys used to encrypt other keys, with different kinds of encryption and formats each time... [1]: https://matrix.org/docs/spec/client_server/r0.6.1 https://matrix.org/docs/spec/client_server/r0.6.1 [2]: https://spec.matrix.org/unstable/client-server-api/ https://spec.matrix.org/unstable/client-server-api/ [3]: https://matrix.org/docs/guides/implementing-more-advanced-e-2-ee-features-such-as-cross-signing/ https://matrix.org/docs/guides/implementing-more-advanced-e-... [4]: AFAICT there is no stable version of [2]. [1] is not it; [1] and [2] have completely different content. Eg [2] explains how "m.secret_storage.key.<key_id>" events work, but this information is not present in [1]. [5]: As a concrete example, I've been working on deriving secret keys from passphrases for a few days, but it always derived the wrong key. I finally figured out why this morning - [3] implies the salt is base64-encoded but it's actually utf8-encoded, so I was decoding it incorrectly. [6]: https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Params#properties https://developer.mozilla.org/en-US/docs/Web/API/Pbkdf2Param...

miloignis 5y ago
I believe that [1] is indeed the stable version of [2] - [2] contains things that [1] does not because it has new bits merged into it that have not yet been in a stable release. I think some of the confusion stems from them also swapping to a new version of the webpage in [2] that hasn't rolled out to the stable spec in [1] yet. Good warning on the JS stuff, I actually just started reading through the E2EE docs again to prep for my client, and I appreciate the heads up!
- Arnavion 5y ago
  It is impossible to implement E2EE without the information in [2] that is not present in [1]. [2] is how you get access to the storage key that Element etc used to store encrypted secrets in your account data. So if anyone's goal is to build a Matrix client that's actually useful, [2] is unavoidable.