
Ask HN: Is OMEMO a good alternative to Signal for federated XMPP? - runn1ng
I recently learned about OMEMO, which is trying to replicate what Signal did with double ratcheting, but on top of Jabber&#x2F;XMPP.<p>https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;OMEMO<p>What does the HN community think about this protocol? Is it a good idea?<p>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).<p>Conversations seem nice, but I don&#x27;t like this quote from wikipedia - &quot;E2E encryption there are OpenPGP, OTR Messaging, and OMEMO to choose from.&quot;<p>I am not sure more choice is good in this case. But I don&#x27;t know the application itself, maybe it&#x27;s done well.<p>(edit: well, it looks a bit confusing in the app itself, unfortunately. https:&#x2F;&#x2F;conversations.im&#x2F;images&#x2F;screenshot_encryption_selection.jpg Default is plaintext?)<p>Also, how is the server support? How error prone is it, etc.<p>edit: also, how is the support of group chat (like Signal has) and of synchronizing devices (like Signal has with mobile-desktop sync)
======
inputmice
Co-author of the OMEMO standard and lead developer of Conversations here. To
answer your question one after the other.

> 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](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...](https://github.com/siacs/Conversations/blob/master/README.md#omemo)

