4 ms·

> What alternate projects are people excited about that are solving the problem of distributed cryptographic identity and messaging? I would argue Matrix is a

by cyphar 7y ago

> What alternate projects are people excited about that are solving the problem of distributed cryptographic identity and messaging? I would argue Matrix is a good contender. The Matrix project is working on secure messaging, and they have a lot of really cool solutions for key distribution and federated communication. "Distributed cryptographic identity" is a slightly hard concept to pin down. In Matrix this is still an open problem, but that's just for the service which links third-party IDs (phone numbers, email addresses, etc) to Matrix IDs (@cyphar:cyphar.com, for instance). But if the problem is distributing keys, then that is a solvable problem. But then again, maybe a different solution is needed to fill the PGP niche.

tptacek 7y ago
The best replacement to PGP would be a messaging network with opt-in, poorly supported encryption? https://www.reddit.com/r/privacy/comments/9avyen/sad_state_of_e2ee_in_matrix_clients/ https://www.reddit.com/r/privacy/comments/9avyen/sad_state_o... I don't know what it is with people and Matrix. It seems like a good project, hamstrung by its overzealous cheering section.
- cyphar 7y ago
  > opt-in Device cross-signing (from my understanding, the last must-have feature before e2ee is considered ready to be the default) is very close to being merged now that Matrix 1.0 is out. Yes, it took several years to get there, but I think its fair to say that the e2ee design now looks much better than anything else available (and had to solve many more technical problems than [for instance] Signal, due to the needs of federation). > poorly supported There are many unmaintained Matrix clients (this is what the top comment of your link points out). Personally I'd prefer if they stopped advertising them on matrix.org, because all of the newer clients either do or will support e2ee. > hamstrung by its overzealous cheering section Given that it seems to be the only project that provides modern e2ee in a way where your data is actually controlled by you without a central authority, I'm surprised that so few people are cheering them on.
  - tptacek 7y ago
    "All newer clients either do or will support e2ee" is my favorite thing I've ever heard someone say about Matrix.
    - Arathorn 7y ago
      well, it's true - if you run a daemon like pantalaimon, even one-liner Matrix requests via curl can speak full E2EE. So arguably the older clients now support E2EE too :)
  - pgeorgi 7y ago
    > Given that it seems to be the only project that provides modern e2ee in a way where your data is actually controlled by you without a central authority, ... OMEMO on XMPP?
- Arathorn 7y ago
  (Matrix project lead here.) The linked reddit post is 10 months old, and even then was riddled with bugs (it ignored or declared 'unclear' for some of clients which had E2E, and included loads of random alpha ones to make the situation seem way worse than it was). The topmost reply on that post tried to correct it at the time, but seems like people don't read the replies. The current situation is that the following clients in Matrix have full E2E support: * Riot/Web (JS) (aka Riot/Desktop) * Riot/iOS (ObjC) * Riot/Android (Java) * RiotX/Android (Kotlin) * Weechat (Python) * Pantalaimon (Python) * Seaglass (ObjC on macOS) * Nheko (Qt) (other than file transfer) Meanwhile, Quaternion (Qt) is currently getting support via GSoC 2019, and the purple-matrix plugin has working (albeit read-only) E2E support. I believe Pattle (pattle.im) is working on E2EE too. And the matrix-python-sdk (not an app) got support via GSoC 2018. It's true that there are over 100 other Matrix clients out there which don't speak E2EE natively, but that's because "a matrix client" can be as simple as a curl one-liner, and so there are tonnes of experimental and toy and alpha ones as well as the more mature ones which you could use to pad out a list to make native E2EE support look bad. However, and most importantly, Pantalaimon (https://github.com/matrix-org/pantalaimon https://github.com/matrix-org/pantalaimon) makes any Matrix client (including all the ones in that FUDdy Reddit post) speak full E2EE - by running as a clientside daemon which acts as a friendly MITM for your Matrix traffic and offloads all the hard E2E encryption (and E2E indexing and search, and in future multiplexing multiple local Matrix apps onto one connection to your server - thus acting almost as a general comms daemon which can even be used as a self-sovereign encrypted push service). That said, I agree that sometimes the enthusiasm of the Matrix community can be overzealous. For instance, there are some bits which we haven't solved yet, for instance: * Cross-signing keys for one-hop web-of-trust is 1-2 weeks away from landing. It's implemented in Synapse and matrix-js-sdk, but we're in the middle of adding it into the UI for Riot/Web currently. You can see demos at the SDK level at https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-06-14#crypto https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-... if interested. We also need to figure out how to use cross-signing for limited transitive web-of-trust (e.g. within an closed organisation where WOT metadata leakage isn't a concern) * We don't turn on E2E by default yet for private chats. This is because we want cross-signing to land first, for usability, and also because we don't want to lock out non-E2E-capable clients, and pantalaimon is only a few weeks old. We also want to better solve e2e-search first (by taking the tantivy-powered FTS indexer from pantalaimon and putting it into Riot). Also, we are still chasing down a few edge cases where session keys aren't available - see https://www.youtube.com/watch?v=WgikPxIjsWE https://www.youtube.com/watch?v=WgikPxIjsWE for our approach to that, and https://github.com/vector-im/riot-web/issues/6779 https://github.com/vector-im/riot-web/issues/6779 for the overall bug. * We don't have any equivalent of key-servers at all yet. So yeah, we definitely don't claim to be perfect, but please don't disregard our progress thanks to a confused/malicious Reddit article.

by cyphar 7y ago

tptacek 7y ago

The best replacement to PGP would be a messaging network with opt-in, poorly supported encryption? https://www.reddit.com/r/privacy/comments/9avyen/sad_state_of_e2ee_in_matrix_clients/ https://www.reddit.com/r/privacy/comments/9avyen/sad_state_o... I don't know what it is with people and Matrix. It seems like a good project, hamstrung by its overzealous cheering section.

cyphar 7y ago
> opt-in Device cross-signing (from my understanding, the last must-have feature before e2ee is considered ready to be the default) is very close to being merged now that Matrix 1.0 is out. Yes, it took several years to get there, but I think its fair to say that the e2ee design now looks much better than anything else available (and had to solve many more technical problems than [for instance] Signal, due to the needs of federation). > poorly supported There are many unmaintained Matrix clients (this is what the top comment of your link points out). Personally I'd prefer if they stopped advertising them on matrix.org, because all of the newer clients either do or will support e2ee. > hamstrung by its overzealous cheering section Given that it seems to be the only project that provides modern e2ee in a way where your data is actually controlled by you without a central authority, I'm surprised that so few people are cheering them on.
- tptacek 7y ago
  "All newer clients either do or will support e2ee" is my favorite thing I've ever heard someone say about Matrix.
  - Arathorn 7y ago
    well, it's true - if you run a daemon like pantalaimon, even one-liner Matrix requests via curl can speak full E2EE. So arguably the older clients now support E2EE too :)
- pgeorgi 7y ago
  > Given that it seems to be the only project that provides modern e2ee in a way where your data is actually controlled by you without a central authority, ... OMEMO on XMPP?
Arathorn 7y ago
(Matrix project lead here.) The linked reddit post is 10 months old, and even then was riddled with bugs (it ignored or declared 'unclear' for some of clients which had E2E, and included loads of random alpha ones to make the situation seem way worse than it was). The topmost reply on that post tried to correct it at the time, but seems like people don't read the replies. The current situation is that the following clients in Matrix have full E2E support: * Riot/Web (JS) (aka Riot/Desktop) * Riot/iOS (ObjC) * Riot/Android (Java) * RiotX/Android (Kotlin) * Weechat (Python) * Pantalaimon (Python) * Seaglass (ObjC on macOS) * Nheko (Qt) (other than file transfer) Meanwhile, Quaternion (Qt) is currently getting support via GSoC 2019, and the purple-matrix plugin has working (albeit read-only) E2E support. I believe Pattle (pattle.im) is working on E2EE too. And the matrix-python-sdk (not an app) got support via GSoC 2018. It's true that there are over 100 other Matrix clients out there which don't speak E2EE natively, but that's because "a matrix client" can be as simple as a curl one-liner, and so there are tonnes of experimental and toy and alpha ones as well as the more mature ones which you could use to pad out a list to make native E2EE support look bad. However, and most importantly, Pantalaimon (https://github.com/matrix-org/pantalaimon https://github.com/matrix-org/pantalaimon) makes any Matrix client (including all the ones in that FUDdy Reddit post) speak full E2EE - by running as a clientside daemon which acts as a friendly MITM for your Matrix traffic and offloads all the hard E2E encryption (and E2E indexing and search, and in future multiplexing multiple local Matrix apps onto one connection to your server - thus acting almost as a general comms daemon which can even be used as a self-sovereign encrypted push service). That said, I agree that sometimes the enthusiasm of the Matrix community can be overzealous. For instance, there are some bits which we haven't solved yet, for instance: * Cross-signing keys for one-hop web-of-trust is 1-2 weeks away from landing. It's implemented in Synapse and matrix-js-sdk, but we're in the middle of adding it into the UI for Riot/Web currently. You can see demos at the SDK level at https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-06-14#crypto https://matrix.org/blog/2019/06/14/this-week-in-matrix-2019-... if interested. We also need to figure out how to use cross-signing for limited transitive web-of-trust (e.g. within an closed organisation where WOT metadata leakage isn't a concern) * We don't turn on E2E by default yet for private chats. This is because we want cross-signing to land first, for usability, and also because we don't want to lock out non-E2E-capable clients, and pantalaimon is only a few weeks old. We also want to better solve e2e-search first (by taking the tantivy-powered FTS indexer from pantalaimon and putting it into Riot). Also, we are still chasing down a few edge cases where session keys aren't available - see https://www.youtube.com/watch?v=WgikPxIjsWE https://www.youtube.com/watch?v=WgikPxIjsWE for our approach to that, and https://github.com/vector-im/riot-web/issues/6779 https://github.com/vector-im/riot-web/issues/6779 for the overall bug. * We don't have any equivalent of key-servers at all yet. So yeah, we definitely don't claim to be perfect, but please don't disregard our progress thanks to a confused/malicious Reddit article.