- cross-posted to:
- tech@pawb.social
- cross-posted to:
- tech@pawb.social
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?
You must log in or register to comment.
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.
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.
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.”
