There are no known security issues with "Siacs OMEMO" / OMEMO v0.3¹ despite of what some very loud Signal fans would like you to believe. It has been audited by a third party² who took a longer look at it than all of the Signal fans combined.
Yes, #OMEMO v0.7+ (or TWOMEMO 😜) is a cleaner spec with more features (most notably Stanza Content Encryption). That’s why we wrote it. I’m a co-author. That doesn’t mean v0.3 is insecure.
¹: xmpp.org/extensions/attic/xep-…
²: conversations.im/omemo/audit.p…
#XMPP
OMEMO Encryption
This specification defines a protocol for end-to-end encryption in one-on-one chats that may have multiple clients per account.Andreas Straub
FediVerseExplorer likes this.
reshared this
Patrick Georgi
in reply to Daniel Gultsch • • •Most of those Signal fans probably refer to a certain blog post by a certain hobby cryptographer. [edit to add: specifically not linked or named because that person doesn't like "evangelists" for messengers-that-aren't-Signal near them. I respect that.]
One argument there holds water, though: OMEMO use is opt-in, and with opportunities to opt-out.
That's different from what Signal offers, and a foot-gun that is way too simple to trigger. (On the down-side, Signal can't opt-out of data being processed in the US. Trade-offs! 🤷)
All the fluff about this-algorithm-or-that or dependency management in Conversations (their solution is dependabot, unvetted-updates-as-a-service. really?!?) is minor compared to that one aspect.
The expectation should be that stuff is E2EE, with carefully (and loudly announced) exceptions where reasonable (when using XMPP as an internal bus protocol, you might be able to get away without it; when running a client on retro gear, you might get better mileage without the crypto overhead, too - but these must be exceptions, not semi-automatic fallbacks)