- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
This blog post, and some of its comments are pretty interesting and concerning at the same time. Not really sure if in the end that means that nothing other than centralized controlled messaging can be as cryptography safe.
Any comments?
Well, there is something mentioned about latest version of omemo:
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:
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:
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.
I see, thanks !
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.
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.
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.
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.