Ask HN: Is OMEMO a good alternative to Signal for federated XMPP?
https://en.wikipedia.org/wiki/OMEMO
What does the HN community think about this protocol? Is it a good idea?
And also, how are the actual implementations? From my experience, OTR implementations were horrible and often incompatible with each other, and I ended up going back to plaintext (oh, the times before Signal).
Conversations seem nice, but I don't like this quote from wikipedia - "E2E encryption there are OpenPGP, OTR Messaging, and OMEMO to choose from."
I am not sure more choice is good in this case. But I don't know the application itself, maybe it's done well.
(edit: well, it looks a bit confusing in the app itself, unfortunately. https://conversations.im/images/screenshot_encryption_selection.jpg Default is plaintext?)
Also, how is the server support? How error prone is it, etc.
edit: also, how is the support of group chat (like Signal has) and of synchronizing devices (like Signal has with mobile-desktop sync)
1 comment
[ 2.5 ms ] story [ 9.6 ms ] thread> What do we think about this protocol?
It's the first encryption protocol that allowed me to actually use it on a daily basis. I regularly use my desktop client and my mobile client in parallel and switch between them constantly. OMEMO allows me to do that.
> Is it a good idea?
Yes. Compared to OTR the entire stack (that includes the XMPP layer) is properly standardized. This also kinda answers your questions regarding the OTR implementations. OTR had the problem that it couldn't do multiple devices and the behavior regarding multiple devices and when to start and end sessions wasn't defined at all. All OMEMO developers are also in regular contact to coordinate behavior between the apps.
> Why are there three encryption choices I would really like to get rid of OTR (and we will eventually) but we currently still need it for backwards compatibility with older clients (primarily Pidgin) PGP servers a bit of a different use case. It doesn't provide forward secrecy and authentication but it turn allows for a server-side re-retrievable archive. If you get a new client it can automatically retrieve old messages. (In OMEMO the receiving must exist at the time of writing. It doesn't have to be online but it has to exist and announced the device specific key material)
In reality the choice isn't too much of a problem. You select it once per contact and that's it. It's not like you are getting new contacts every day.
> How is the server support.
The server requirements for OMEMO aren't too bad. However it is recommended that you do pick a modern XMPP server for other reasons (battery-friendliness, reliability). Have a look at this comparison list to see if your server supports all modern extensions: https://gultsch.de/compliance_ranked.html
> How is the support of group chat
Support for group chat exists and works fine once it is setup. However it has some limitations that make setup harder. Everyone has to be in everyone elses contact list. And the group needs to be setup with special parameters. (Conversations automatically sets it up this way, but you couldn't for example create the group with Pidgin and then expect OMEMO to work.) The readme on the Conversations github page explains this in a little more detail: https://github.com/siacs/Conversations/blob/master/README.md...