138
Best apps for private messaging (www.privacyguides.org)
submitted 8 months ago by to c/opensource@lemmy.ml
91 comments fedilink hide all child comments
 

Hello. I am looking for an alternative to Telegram and I prefer an application that uses decentralised servers. My question is: why is the xmpp+omemo protocol not recommended on websites when it is open source and decentralised? The privacyguides.org website does not list xmpp+omemo as a recommended messaging service. Nor does this website include it in its comparison of private messaging services.

https://www.privacyguides.org/en/assets/img/cover/real-time-communication.webp

Why do you think xmpp and its messaging clients such as Conversations, Movim, Gajim, etc. do not appear in these guides?

you are viewing a single comment's thread
view the rest of the comments
[–] 2 points 8 months ago (3 children)

OMEMO leaks plenty of metadata

Could you even cite an example of such leaked metadata? I'd like to also remind you that metadata leaking to your own server (which you can chose, which you can self-host) isn't as big a deal in XMPP as it is with other services. Which is also why I can't take Soatok's opinion about and obsession for Signal seriously: when all accounts are hosted by a single actor, you have a much bigger metadata problem, and all obfuscation attempts (sealed senders being one) are ultimately defeated by simple timing and packet correlation attacks.

I spent 40 min scouring Snikkets website and source repo without any clear way to determine what version of OMEMO they bundle.

You were probably looking at a rebrand/spin of https://xmpp.org/software/conversations/ . All major XMPP clients and servers declare their compat via DOAP: https://xmpp.org/extensions/xep-0453.html

My point is that security is independent of adoption.

Correct, but in this case OMEMO is secure and is used in contexts where security actually matters. There have been multiple audits of it over the years:

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 3 points 8 months ago (2 children)

    From the OMEMO XEP specification under section 2.1 "Threat Model" https://xmpp.org/extensions/xep-0384.html#reqs-threat-model

    The OMEMO protocol does not protect against attackers who rely on metadata and traffic analysis.

    Off-topic, I would also like to add that the spec says " It has been demonstrated, that OMEMO provides only weak forward secrecy (it protects the session key only once both parties complete the key exchange).", citing https://www.cypherpunks.ca/~iang/pubs/dakez-popets18.pdf

    The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content. Look under sections 1.2 and 4.4 to see what I mean about there being no mention encrypting other data (eg. recipients and room names). This means that sender/receiver are (most likely) not encrypted. I don't think (though I don't know for sure) that room names are encrypted either.

    What happens if you communicate/participate in an encrypted chat/user on another server? Could the server owner now see the other unencrypted data and metadata?

    Also, just because you self host it doesn't make the unencrypted (meta)data any less dangerous. That just makes your server the point of failure. By your logic, why encrypt at all? It all lives on your server, it is only a problem if someone has access to your server. Networking is encrypted with TLS anyways, so why bother. /s

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 8 months ago (1 child)

    The specification only seems to say that message content are encrypted, making no mention of encrypting any other data than message content.

    Correct, what's not encrypted are things like typing notifications, read markers, recipients. Which was my whole point: this is inferred easily by the server anyway: it hosts your account and your contacts list already, it routes your messages to recipients and across the whole network. You can't really operate without this level of trust. Neither in XMPP nor in Signal.

    Also, just because you self host it doesn’t make the unencrypted (meta)data any less dangerous.

    You seem to hold a very naive take on all of this. This is the basis of federation. In a centralised system (Signal), everyone must trust that the one provider to act (and keeps acting) in good faith. Federation loosens this by having you trust a provider of your choice, and by giving you the ability to move on otherwise. Zero-trust is only theoretically achievable with peer-to-peer, but we have yet to come-up with a system that is performant and efficient enough at scale to be deemed usable. P2P networks often resort to edge gateways to do some caching or connection brokering, and at that point you are back to the same tradeoffs as with federation, only with more steps and worse results.

    That just makes your server the point of failure.

    Always was, always will be. Like I said, remove the server and you are onto something… Make it work well, and you will be the first, and do the world a great service.

    By your logic, why encrypt at all?

    E2EE is one mitigation against one type of threat. Not a silver bullet.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •