XMPP (aka Jabber) is the community-owned standard for real-time federated messaging.
JoinJabber.org admin support chat
Despite the strong opinions expressed, they didn't actually find any real issues?
It's clear that they have no objections against the latest version of OMEMO (which is very similar to Signal's e2ee anyways), and the problem with the earlier version is more theoretical in nature. But yes, it would be nice if more clients would upgrade to OMEMO v0.8, but at least for Conversations there are some upstream library deficiencies that make it hard to do so.
Well, there is something mentioned about latest version of omemo:
OMEMO doesn’t attempt to provide even the vaguest rationale for its design choices, and appears to approach cryptography protocol specification with a care-free attitude.
To put it mildly, this is the wrong way to approach cryptography
...
Because there is no rationale given for this sudden square-root reduction in security against existential forgery attacks, we kind of have to fill in the gaps and assume it was because of some kind of performance or bandwidth considerations.
But even that doesn’t really justify it, does it?
You’re only saving 16 bytes of bandwidth by truncating the MAC. Meanwhile, the actual ciphertext blobs are being encoded with base64, which adds 33% of overhead.
For any message larger than 48 bytes, this base64 encoding will dominate the bandwidth consumption more than using the full HMAC tag would.
...
Is truncating the HMAC tag to to 128 bits still secure? According to Signal, yes, it is. And I offer no disagreement to Signal’s assessment here.
The problem is, as I’ve said repeatedly, OMEMO’s specification makes no attempt to justify their design decisions.
Then on one of the comments, there's an interesting comment on something signal has mentioned it's working on quantum resistance, that it's no clear is something omemo will support, and even less when clients might adopt if eventually available:
Indeed quite often someone compares the two protocols and implies OMEMO is as mature as the current state of the art Signal protocol. Allow me to throw in the emerging post-quantum support that Signal is adding or already has in libsignal.
Somehow is implied on the comment that omemo is immature compared to libsignal...
At any rate, dino uses libsignal-protocol-c (on Artix/Arch 2.3.3), not libomemo, and conversations uses libaxolotle-java (according to the "about" section in the settings). So somehow using signal library underneath. Although I have no idea how up to date with regards to the signal library those might be (though the axolotl dependency on conversations allows to think it's outdated). And for conversations the author mentions:
To be clear: These aren’t separate dependencies that Conversations pulls in to implement plugin supports. They’re first-party cryptographic implementations all within this Android app’s codebase.
I guess by 1st party the author means like copy/paste the code (with local twists, which might be dangerous but perhaps necessary) to have a local version of the libraries. This sounds like a non version related criticism, but it's client related rather than protocol related, however the author mentions other clients are way worse, leaving no hope...
I don't see on dino an option to always use omemo BTW, not sure if dino just it implies omemo by default, but it doesn't have a way to force it. Perhaps a feature to ask dino developers...
At any rate, according the post there's little hope for xmpp + omemo. Which was actually something I was still hoping for, well, besides getting jami working at some point (but it has crypto issues on its own, including lack of auditing).
I don't find "the change-log lacks detail" to be a serious critique. That's just grasping for straws to support a preconceived opinion.
As for "post-quantum" encryption... I have a hard time taking people serious that use such buzz-words, when quantum computing is still largely a theoretical concept with no real-world application. Sure, it's worth researching cryptographic concepts that are resilient to this hypothetical attack, but everyone that peddles that stuff today in e2ee messengers is a snake-oil vendor.
As for mandatory e2ee, let's just say that opinions differ on that, and it's not a valid critique of the security of a messenger whether nor not it enforces e2ee. I personally prefer choice with good defaults.
The author of the article is a professional cryptographer with a long history of writing human-readable articles on serious cryptographic subjects. I think it would be polite to give them the benefit of the doubt and assume that they are not being a hater for the fun of it, especially when they've shown their work.
Cryptography is to be taken very seriously. One implementation bug or one weak attack vector and you're done. If you're switching your algorithms around and not explaining why it's very reasonable for a cryptographer to wonder what exactly you think you're doing, and whether the implementation is in good hands. Maybe there are valid reasons for these changes, but we shouldn't have to guess on something this important. If this article is what it takes to get clarification from the OMEMO authors on what exactly their design is, that is a positive outcome for everyone.
If you think post-quantum is "snake oil" you clearly don't know the first thing about cryptography, so why are you putting on a confident face here and disparaging the author instead of taking a few moments to research the topic first? Hint: pre-quantum communications can be captured and stored, to await the power of quantum computing to crack them. Post-quantum means that your conversations today remain safe tomorrow.
The OMEMO authors have already responded to the point about the changelog, and it turns out the key length was always truncated like this (which is fine as Soatok themselves admit) and the change in the version they point out was only a slight wording change to emphasise this, not an actual spec change.
That Soatok jumps on this in their article without checking what the spec actually was in previous versions makes me think they didn't really look very closely, but rather just looked for superficial support of their preconceived opinion.
As for post-quantum encryption: without knowing what quantum computers are really capable of, you can only speculate how to protect against them. The various proposals for that are highly debated and often turn out to be not any better or sometimes even worse than existing well established encryption methods.
Encryption is indeed a serious matter, as you say yourself. Peddling unproven and half-baked "post-quantum” encryption algorithms that might in fact lower and not higher protection against current and future attacks is not serious.
The serious response is to say we don't know at the current time what can protect against possible future quantum computers and subsequentially minimize data retention and only use well proven state of the art encryption algorithms. Coincidentally XMPP is doing exactly that.
That Soatok jumps on this in their article without checking what the spec actually was in previous versions makes me think they didn’t really look very closely, but rather just looked for superficial support of their preconceived opinion.
Looking in the spec design document instead of digging through the source code is normally enough research in other projects where the spec design document is properly filled out. It's a mistake on OMEMO's part that the spec design document didn't include the truncation step in 0.4.0, and this mistake was fixed in their 0.7.0 version. Either way, as I said this is a positive outcome because now we have clarification.
I briefly recounted the points made in the article and I think this was the only one that was against OMEMO directly. Soatok made another post days earlier about why nothing on the market is currently better than Signal, and it makes sense that the other 3 points are still being leveraged against XMPP+OMEMO as they exist in reality, and not against OMEMO alone. It doesn't matter that OMEMO 0.7.0 is sufficient if nothing is using it, and the various implementations have their own issues. If you were to want to use XMPP+OMEMO today, you're likely using Gajim, Dino, or Conversations, or someone you're talking to is. These are still on 0.3, and this is a point that again is important to bring up and potentially solve. If no one is talking about the problem, it will not get solved.
RE quantum encryption, we know what quantum computers are capable of. You've suddenly turned into a quantum expert so you must now know that you only really need to protect your asymmetric encryption with PQ, and you would also know that you can combine PQ and traditional algorithms together in cases where you don't want to degrade existing security if there are flaws in the newer PQ algorithm. This would be the "serious" response, and "serious" software like Signal agrees.
I was in the specs before as well, just not as clearly spelled out.
As for the other reasons why Soatok thinks Signal is better, well those are cherry picked and highly opinionated. There are similar lists of reasons from equally respected security researchers (that have less of a e2ee tunnel vision), that rule out Signal as a serious option due to its centralised and single vendor approach.
Which brings me to the last point. Yes, Signal is a snake-oil vendor that tries to hide the various glaring security issues of their model behind a state of the art e2ee system. But that's just a fig-leaf not really all that different from how WhatsApp claims to be secure due to them adopting e2ee.
Post-quantum encryption is an active R&D field with no proven to work solutions yet. In fact, solutions that are proudly announced as finally having solved it are regularly silently retracted as other researchers find that they actually offer less security than current state of the art encryption algorithms.
As for the other reasons why Soatok thinks Signal is better, well those are cherry picked and highly opinionated
In the Signal article yes, by design those are his opinions on what the minimum requirements are for "beating Signal", which are not all objective truths. These articles come from a response to people evangelizing one messenger or another to him, some of which have "stronger" security but negatives in other places that make them unacceptable for widespread use (especially for non-techies). In the XMPP article I think the remaining points are very fair in terms of how the XMPP ecosystem works today.
Signal is a snake-oil vendor
Post-quantum encryption is an active R&D field with no proven to work solutions yet
Okay, that's enough of my time. These replies are for the benefit of others, and I hope I've said enough on that for people to make their judgments with more info that what you initially were responding with.
I see, thanks !
I'm not a cryptographer, and so I can't really emit a judgement on the poster's abilities or reputation, but what's for sure is that this piece reads more like a bingo card of a person's favourite "crypto stuff" and how partially it overlaps with some characteristics of OMEMO, rather than a thorough and substantiated cryptanalysis of the protocol and its flaws for real-world usages and threats.
Some snarky remarks remarks like
OMEMO doesn’t attempt to provide even the vaguest rationale for its design choices, and appears to approach cryptography protocol specification with a care-free attitude.
are needlessly opinionated, inflammatory and unhelpful, and tell more about the author and their lack of due diligence (in reaching-out to people and reading past public discussions) than build a story of what the problem is, why it matters, and how to remediate it.
Don't get me wrong, I would love this piece to have been something else, and to reveal actual problems (which incidentally would have been a great boos to the author's credibility and fame, considering that OMEMO underwent several audits and assessments in the recent history, including by several state agencies in the German and French governments…), but here we are, with one more strongly opinionated piece of whatever on the internet, and no meat in it to make the world a better place.
I see your point, many thanks !
I'm not the right person to address anything there...far beyond me. But this line seems under-emphasized: "Maybe part of the blame is a lack of investment...in the XMPP developer community."