6 ms·

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not under

by a3w 5y ago

Encryption is "activily bein worked on", sound about right - I never got encryption to work across two of my own devices with a third party. Yet I do not understand why a rewrite of messaging as [matrix] was necessary, when XMPP was already there and matrix did not even have an edit-message feature on release, perhaps not even now.

_zooted 5y ago
Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.
- zaik 5y ago
  > Most of the time the way key exchange is done in XMPP is very insecure. How so?
- f1refly 5y ago
  > Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.
  - gefhfffh 5y ago
    How resistant to MITM is it though? Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time. Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix]. This opens room for MITM attacks
    - f1refly 5y ago
      Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere? Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key. In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident. > This opens room for MITM attacks Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.
      - southerntofu 5y ago
        > How should a "per user" verification work in your opinion? The server could keep an append-only log of published keys, and then you could require m-of-n signatures of other published devices/keys to register a new one, in which case no further verification would be verifiable if you already trusted your peer's other keys. In addition, you could introduce peer keys in private rooms automatically and/or employ some form zero-knowledge proofs in public venues. XEP-0450 Automated Trust Management is a first exploration in this direction. There a lot to explore and I only wished skilled cryptographers spent more time researching these issues on federated networks instead of advancing yet-another-centralized-messenger-of-the-month. > Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Also known as a keyserver. But you could also employ cryptographic challenges like OTR does, like a shared password to establish the session.
      - ddtaylor 5y ago
        That sounds significantly more complex and worse than how Matrix just works out of the box.
        f1refly 5y ago
        Omemo just works out of the box as well. You don't have to check the key fingerprints, noone forces you to. For people who aren't interested the chat opens and they can start writing and sending, the encryption is completely transparent.
        doctor_lollipop 5y ago
        I wouldn't say that it's completely transparent, at least not when you use multiple clients (eg. a PC and a phone). I frequently get messages that some device cannot decrypt.
      - easrng 5y ago
        Why not do crosssigning like matrix?
- ezst 5y ago
  > Matrix supports encryption out-of-the-box that's not true for most clients, though (AFAICT, only riot works with itself). I might even say that the situation is better/more sustainable in XMPP where more diverse implementations of the encryption protocol are available, with all mainstream clients supporting it: https://omemo.top/ https://omemo.top/
  - kitkat_new 5y ago
    FluffyChat and Syphon are doing pretty well. I don't think any of the clients are mainstream Riot doesn't exist anymore. It's been Element for a while now
123pie123 5y ago
from https://github.com/movim/movim/issues/63 https://github.com/movim/movim/issues/63 >"edhelas commented Nov 26, 2021 As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done. It took 6 years but Movim is finally having end to end encryptio edhelas commented Nov 26, 2021 As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done. It took 6 years but Movim is finally having end to end encryption."
gefhfffh 5y ago
Well, matrix does a lot of things different. A rewrite seems pretty unavoidable with hat many and significant changes
- southerntofu 5y ago
  What's so different about it? Historically XMPP was more geared towards message-passing without server-side archival, but that ship has long since sailed to support multi-client. As it is, i don't see any significant change except for the consensus algorithm for decentralized rooms which could very well be an extension to the XMPP s2s protocol.
  - pkulak 5y ago
    https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/faq/#what-is-the-difference-between-matri...
    - southerntofu 5y ago
      Yes i understand that Matrix is a consensus-assembled JSON database. For the sake of argument, this could have been developed as an XMPP extension. In real life, you don't need or want a distributed consensus for simpler federated chat: it's been the cause of so many troubles across the Matrix ecosystem (room version incompatibilities, room takeovers due to netsplit, bad performance) that it's actually an argument against that building block. Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense.
      - kitkat_new 5y ago
        room versions are incompatible naturally and room takeovers were a bug. So saying it's the cause for these things, is misleading. At this time there are 9 room versions. Once the room version had to be incremented because of a bug in the consensus algorithm, which required a new algorithm, i.e. room version. That's it. Bugs happen when you create new tech... > Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense. There are many more reasons for wanting decentralized rooms, e.g. autonomy, reliability, availability, anti-takeover - and it works for private rooms as well. Prospectively, it enables things like P2P and multi homing I would never want to go back to the XMPP like it is today. And XMPP today is not Matrix, even if you could turn it to Matrix, but what is the point of doing that? Matrix is already there! If you want Matrix to be an XMPP extension, I suggest creating a new XEP pointing to spec.matrix.org and call it XMPP v2. No idea what you would gain from it though.
f1refly 5y ago
XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.
- zaik 5y ago
  It still would be nice if Matrix was built upon the existing Internet Standard for instant messaging.
  - gefhfffh 5y ago
    How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that? What would be the benefit if that was done?
    - f1refly 5y ago
      The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.
      - rakoo 5y ago
        That's an issue with any cross-protocol accounts, and will only be solved the day something like MLS comes up.
    - rakoo 5y ago
      XMPP has pubsub nodes, which in practice can be used as a general key-value datastore with a push when a key is updated. So it can be done, but at this point it will only be the same functionality with a different API. It doesn't make a lot of sense.
f1refly 5y ago
Depending on when you last tried xmpp you might have experienced the OTR hell, which was never really codified 100% and spawned subtle incompatibilities between clients leading to weird and nondescript errors that never got addressed. Nowadays the popular clients support omemo (https://conversations.im/omemo/ https://conversations.im/omemo/), which makes encryption just work™ out of the box and without hassle. The only exception to this is xabber, who are apparently afraid of law enforcement destroying their lifes should they implement proper encryption and also feel no need to support it anyways: https://github.com/redsolution/xabber-android/issues/540 https://github.com/redsolution/xabber-android/issues/540
- Semaphor 5y ago
  > just work™ YMMV™ We have yet to manage not getting any OMEMO issues in a 2 users, 5 clients situation (2 Conversations on android, 1 Gajim on win, 2 Pidgin on linux)
  - southerntofu 5y ago
    If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.
    - tialaramex 5y ago
      > Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation. Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you thought it did. Here's my unsolicited recommendation: Block Pidgin. Not just Pidgin, any time the XMPP community finds itself having to explain that oops, that client doesn't work so good, please use a different one, just block the client, permanently instead, from all popular and well known servers, tell anybody who will listen that's not a real XMPP client, not any more. Any time the community just can't bring itself to block a client, cross off the features that don't work across the ecosystem due to that client. Those aren't really XMPP features any more since they exist only for some users and the community is apparently OK with that. And each year, stand back and look at the resulting two steps forward three steps back juddering "Progress" and reconsider - was this the way to get where you wanted to go? Or are you all wasting your time on an exercise that would be easier done a different way.
mr_johnson22 5y ago
Perhaps the real distinguishing factor of Matrix isn't its technology, but its governance. Instead of an extensible, plugin-based approach like XMPP, Matrix has just a single "official" spec that can only be extended by amending the spec itself. IIRC this was one of the motivations behind Matrix's inception. As to whether one approach is better than the other is left as an exercise to the reader :) But having each approach belong to separate projects allows them to carry on as they see fit, and means they don't have to participate in a zero-sum game.
- ptman 5y ago
  Most things in matrix are namespaced. The official spec namespace is 'm', as in 'm.text', but you can extend it very liberally by just adding keys like 'com.github.mr_johnson22.matrix.foo'

by a3w 5y ago

_zooted 5y ago

Matrix supports encryption out-of-the-box without any strange key exchange problems. Most of the time the way key exchange is done in XMPP is very insecure.

zaik 5y ago
> Most of the time the way key exchange is done in XMPP is very insecure. How so?
f1refly 5y ago
> Most of the time the way key exchange is done in XMPP is very insecure. We have OMEMO now, key exchange is paranoia-level secure.
- gefhfffh 5y ago
  How resistant to MITM is it though? Currently, verification seems to work on a session basis and not just per user, which makes it very tedious to have everything verified e.g. a group chat. If it is not almost impossible given peoples sessions change with time. Add a new session in the browser -> meet every contact to verify their sessions with your new browser session? Doesn't seem very practical, and reminds me of the old times in [matrix]. This opens room for MITM attacks
  - f1refly 5y ago
    Security is always a tradeoff with convenience. How should a "per user" verification work in your opinion? A single master key that signs subkeys? Would the master key be secured with yet another password? What happens with already signed keys if a user loses access to the master key? Will I have to explain to my auntie over the phone that her master key password is somehow different to her account password and that it's very important she remembers both? Will I have to tell my uncle to sign his new key in the browser session with his master key that was generated on the phone and now has to be transmitted to the computer because it wasn't password protected and thus can't be stored on the providers server for syncing? When existing keys are used to sign new ones, what happens when the old one gets dropped? Will the conversation just break out of nowhere? Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Essentially, if you want 100% security by comparing keys in a meetup, you can do that once and then use that known good channel to verify every new key. In reality, cryptonerds will be happy to verify every single new key, everyone else will never bother to even open the key signature view and I will get a confused call should it be opened by accident. > This opens room for MITM attacks Yes, in your constructed strawman world xmpp is prone to MITM. In reality it's equally or less prone than its competitors.
    - southerntofu 5y ago
      > How should a "per user" verification work in your opinion? The server could keep an append-only log of published keys, and then you could require m-of-n signatures of other published devices/keys to register a new one, in which case no further verification would be verifiable if you already trusted your peer's other keys. In addition, you could introduce peer keys in private rooms automatically and/or employ some form zero-knowledge proofs in public venues. XEP-0450 Automated Trust Management is a first exploration in this direction. There a lot to explore and I only wished skilled cryptographers spent more time researching these issues on federated networks instead of advancing yet-another-centralized-messenger-of-the-month. > Also you don't have to meet with everyone to verify new keys, you can just use a known good key for that. Also known as a keyserver. But you could also employ cryptographic challenges like OTR does, like a shared password to establish the session.
    - ddtaylor 5y ago
      That sounds significantly more complex and worse than how Matrix just works out of the box.
      - f1refly 5y ago
        Omemo just works out of the box as well. You don't have to check the key fingerprints, noone forces you to. For people who aren't interested the chat opens and they can start writing and sending, the encryption is completely transparent.
        doctor_lollipop 5y ago
        I wouldn't say that it's completely transparent, at least not when you use multiple clients (eg. a PC and a phone). I frequently get messages that some device cannot decrypt.
    - easrng 5y ago
      Why not do crosssigning like matrix?
ezst 5y ago
> Matrix supports encryption out-of-the-box that's not true for most clients, though (AFAICT, only riot works with itself). I might even say that the situation is better/more sustainable in XMPP where more diverse implementations of the encryption protocol are available, with all mainstream clients supporting it: https://omemo.top/ https://omemo.top/
- kitkat_new 5y ago
  FluffyChat and Syphon are doing pretty well. I don't think any of the clients are mainstream Riot doesn't exist anymore. It's been Element for a while now

123pie123 5y ago

from https://github.com/movim/movim/issues/63 https://github.com/movim/movim/issues/63 >"edhelas commented Nov 26, 2021 As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done. It took 6 years but Movim is finally having end to end encryptio edhelas commented Nov 26, 2021 As OMEMO is now part of Movim master and that the main working features are working I'm considering this ticket as solved. There is still a lot of small things to fix but the main is done. It took 6 years but Movim is finally having end to end encryption."

gefhfffh 5y ago

Well, matrix does a lot of things different. A rewrite seems pretty unavoidable with hat many and significant changes

southerntofu 5y ago
What's so different about it? Historically XMPP was more geared towards message-passing without server-side archival, but that ship has long since sailed to support multi-client. As it is, i don't see any significant change except for the consensus algorithm for decentralized rooms which could very well be an extension to the XMPP s2s protocol.
- pkulak 5y ago
  https://matrix.org/faq/#what-is-the-difference-between-matrix-and-xmpp%3F https://matrix.org/faq/#what-is-the-difference-between-matri...
  - southerntofu 5y ago
    Yes i understand that Matrix is a consensus-assembled JSON database. For the sake of argument, this could have been developed as an XMPP extension. In real life, you don't need or want a distributed consensus for simpler federated chat: it's been the cause of so many troubles across the Matrix ecosystem (room version incompatibilities, room takeovers due to netsplit, bad performance) that it's actually an argument against that building block. Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense.
    - kitkat_new 5y ago
      room versions are incompatible naturally and room takeovers were a bug. So saying it's the cause for these things, is misleading. At this time there are 9 room versions. Once the room version had to be incremented because of a bug in the consensus algorithm, which required a new algorithm, i.e. room version. That's it. Bugs happen when you create new tech... > Except of course for censorship-resilient public rooms where it shines, which goes back to my point that "decentralized rooms" as an XMPP extension would have made sense. There are many more reasons for wanting decentralized rooms, e.g. autonomy, reliability, availability, anti-takeover - and it works for private rooms as well. Prospectively, it enables things like P2P and multi homing I would never want to go back to the XMPP like it is today. And XMPP today is not Matrix, even if you could turn it to Matrix, but what is the point of doing that? Matrix is already there! If you want Matrix to be an XMPP extension, I suggest creating a new XEP pointing to spec.matrix.org and call it XMPP v2. No idea what you would gain from it though.

f1refly 5y ago

XMPP and matrix solve related, but somewhat different problems. The Matrix approach is that everything is a stateful chatroom with history in which users can join or leave, while for XMPP there are only users (entities) which exchange objects that may or may not be text messages. It doesn't really care what happens after the fragments have been delivered.

zaik 5y ago
It still would be nice if Matrix was built upon the existing Internet Standard for instant messaging.
- gefhfffh 5y ago
  How would it be even possible to build Matrix, as it is today, on XMPP? And, more importantly, why would you want to do that? What would be the benefit if that was done?
  - f1refly 5y ago
    The benefit would be that history would be kept and be viewable from different accounts. The problem would be that the history would have to be MITM'd on the matrix-xmpp-server-bridge because the encryption models aren't compatible. The server would need to manage omemo keys for the user and would thus need ultimate trust.
    - rakoo 5y ago
      That's an issue with any cross-protocol accounts, and will only be solved the day something like MLS comes up.
  - rakoo 5y ago
    XMPP has pubsub nodes, which in practice can be used as a general key-value datastore with a push when a key is updated. So it can be done, but at this point it will only be the same functionality with a different API. It doesn't make a lot of sense.

f1refly 5y ago

Depending on when you last tried xmpp you might have experienced the OTR hell, which was never really codified 100% and spawned subtle incompatibilities between clients leading to weird and nondescript errors that never got addressed. Nowadays the popular clients support omemo (https://conversations.im/omemo/ https://conversations.im/omemo/), which makes encryption just work™ out of the box and without hassle. The only exception to this is xabber, who are apparently afraid of law enforcement destroying their lifes should they implement proper encryption and also feel no need to support it anyways: https://github.com/redsolution/xabber-android/issues/540 https://github.com/redsolution/xabber-android/issues/540

Semaphor 5y ago
> just work™ YMMV™ We have yet to manage not getting any OMEMO issues in a 2 users, 5 clients situation (2 Conversations on android, 1 Gajim on win, 2 Pidgin on linux)
- southerntofu 5y ago
  If you care to elaborate, i'm sure that'll be of interest to maintainers. Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation.
  - tialaramex 5y ago
    > Although to be fair Pidgin doesn't exactly have the reputation to be maintained (despite recent efforts to start again) so i would strongly recommend to try again without that specific client in the equation. Quality of Implementation matters. If Pidgin "doesn't exactly have the reputation" and yet it's still notionally part of your ecosystem, then your whole ecosystem doesn't exactly deserve the reputation you thought it did. Here's my unsolicited recommendation: Block Pidgin. Not just Pidgin, any time the XMPP community finds itself having to explain that oops, that client doesn't work so good, please use a different one, just block the client, permanently instead, from all popular and well known servers, tell anybody who will listen that's not a real XMPP client, not any more. Any time the community just can't bring itself to block a client, cross off the features that don't work across the ecosystem due to that client. Those aren't really XMPP features any more since they exist only for some users and the community is apparently OK with that. And each year, stand back and look at the resulting two steps forward three steps back juddering "Progress" and reconsider - was this the way to get where you wanted to go? Or are you all wasting your time on an exercise that would be easier done a different way.

mr_johnson22 5y ago

Perhaps the real distinguishing factor of Matrix isn't its technology, but its governance. Instead of an extensible, plugin-based approach like XMPP, Matrix has just a single "official" spec that can only be extended by amending the spec itself. IIRC this was one of the motivations behind Matrix's inception. As to whether one approach is better than the other is left as an exercise to the reader :) But having each approach belong to separate projects allows them to carry on as they see fit, and means they don't have to participate in a zero-sum game.

ptman 5y ago
Most things in matrix are namespaced. The official spec namespace is 'm', as in 'm.text', but you can extend it very liberally by just adding keys like 'com.github.mr_johnson22.matrix.foo'