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.
¹: https://xmpp.org/extensions/attic/xep-0384-0.3.0.html
²: https://conversations.im/omemo/audit.pdf
@daniel 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)
@menel @patrick and #Signal despite their #FUD and #MarketingLies is a very #cebtralized, #SingleVendor & #SingleProvieer system relying on #GAFAMs and their #API|s as well as neither allowing #SelfCustody nor #SelfHosting.
Not to mention it's toxic followers that avt like cultists [infosec.space]!