[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

OTR versus OMEMO

Development
#1

  • OTR is based on OpenPGP while OMEMO is “homemade from scratch”

  • OTR is mainly for 1 to 1 chat while OMEMO mainly for group chat, the problem with group chat is key distribution and verifying is a lot less secure by nature than 1 to 1.

  • OMEMO key verification is more complex and slips in comparing fingerprints by newbie users are very well possible, even advanced users can’t properly verify fingerprint unless they meet in real life or send their fingerprint over another platform, OTR on other hands uses Socialist millionaire protocol instead where users can set human readable questions to other party to verify their identity, aka key-fingerprint. TL;DR: This feature makes it possible for users to verify the identity of the remote party and avoid a man-in-the-middle attack without the inconvenience of manually comparing public key fingerprints through an outside channel.

  • OMEMO wiki states it provides deniability which is not true, OMEMO does not provide good deniability “Deniability: X3DH is weakly offline deniable and provides no online deniability, as far as the research shows.”

  • OMEMO wiki again falsely states perfect forward secrecy which again is totally false “It has been demonstrated that OMEMO provides only weak forward secrecy (it protects the session key only once both parties complete the key exchange).”

  • OTR is more mature and a lot of popular projects are based on it such as Signal

  • OTR messages are smaller in size thus faster sending and receiving

  • OTR does not save message history, while in OMEMO and clients that support OMEMO it is usually impossible/very hard to disable message history

There are probably other reasons that I missed, but those are most of major ones of why OTR is better than OMEMO

@Patrick This post should be added as warning in the Wiki

Update Wiki Chat
Update Wiki Chat
#2

Thoughts? @HulaHoop

#3

A complex question about cryptography. Since I am not an expert on cryptography, you please provide links to audits of either protocol (or even client implementation) or opinions of cryptography experts?

Not sure being OpenPGP based is a pro. OpenPGP, if it would be re-designed from scratch nowadays would look much different. OpenPGP and gpg include too much legacy cruft for compatibility. Link here:

https://www.kicksecure.com/wiki/OpenPGP#Issues_with_PGP

Also gpg chooses compatibility with OpenPGP over security by not setting the default key size to the highest available.

In Debian wiki there are some thoughts (plan?) to move away from gpg due to its issues:

Are you sure? Which OpenPGP standard RFC are you referring to?

Then compare with Off-the-Record Messaging Protocol version 3 to see if there are similarities.

Something to investigate…

https://news.ycombinator.com/item?id=16285135

See also Signal Broken Metadata Protection.

Could also be turned into an anti-OTR argument in theory since Signal modified it? Then one would have to track down the modifications and the rationale.

#4

I meant based on openPGP as in the concept, it is NOT openPGP nor does have same protocol but just based on it as in similar protocol in older versions of OTR. that point was not meant to make OTR look good by saying it’s based off something major but rather it shows the OTR authors expertises in that they didn’t attempt to re-invent the wheel early on

Signal modified it to fit their goal of mobile application voice and video calls, group chats etc, they didn’t modify “the weakness” off it

point still stands that OTR is better than OMEMO in terms of forward secrecy and deniability as well as key exchanging.
I am not saying OTR is best ever but when compared with OMEMO it’s pretty easy to see who wins

#5

Not a cryptographer either but read Ian’s article.

It is not comparing OTR vs OMEMO, it is comparing secure messengers protocols and how to improve their deniability, specifically OTR and Signal protocol.

You cherry-picked OMEMO’s deniability flaws but left OTR’s out why?

3rd paragraph of the Introduction section of Ian’s article:

Unfortunately, popular secure messaging protocols
like OTR and Signal do not provide strong deniability.
A protocol is strongly deniable if transcripts provide no
evidence even if long-term key material is compromised
(offline deniability) and no outsider can obtain evidence
even if an insider interactively colludes with them (on-
line deniability). The limited deniability of current se-
cure messaging tools creates severe privacy weaknesses.

Then you said this without pointing in the wiki where it states that:

Anyway, the main thing I got from the article is:

Signal recently switched to a DAKE known as
“Extended Triple Diffie-Hellman” (X3DH) [75] that im-
proves forward secrecy but regresses to the deniability
properties of OTR’s DAKE. Consequently, real-world
deployments of “deniable” secure messaging protocols
still lack strong deniability.

Signal’s protocol (X3DH) improves forward secrecy and regresses on deniability when compared to OTR’s DAKE.

#6

This is a byzantine debate that discourages pragmatic use of encrypted chat messengers that are already hard to come by that do this correctly from a UX standpoint and are maintained enough to not have any buggy or unexpected behavior. Therefore we should limit the discussion to here and not make any negative warnings on the wiki because in real life either one of these protocols gets the job done.

Now lets look at the detail’s devil

OTRv3 is where the comparison should be made as it was updated to have feature parity with OMEMO.

Neither protocol’s deniability feature had been tested in court successfully AFAIK. If the contents of your messages has been leaked then you have bigger problems to worry about such as betrayal or machine compromise.

Signal was a modernization effort of the OTR protocol and then OMEMO was what democratized the Axolotl protocol that signal uses without having to use the Signal service or deal with its registration requirements.

Not a problem in today’s world with broadband being fast as it is.

That is an XMPP protocol extension feature not really related to OMEMO per se. You can pick a service that doesn’t enable this extension.

Now for what you didn’t mention, OTRv3 is supposed to be cleanly designed when compared to OMEMO and how it handles secure file transfers, however only one modern client supports it (coyIM) and none on the mobile platforms. Giving the impression that OMEMO is unsecure and broken as your criticisms imply would be misleading and harmful for the adoption of privacy software.

1 Like
#7

Maybe you’re right, either one of them gets the job done

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]