the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.
if you actually look at % of impacted clients, it’s tiny.
meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented on in the readme and https://github.com/matrix-org/olm/issues/3 since day 1.
It being unclear that they're exploitable doesn't justify the fact that the reference implementation had known weaknesses that were only documented in the issue tracker and a readme buried several directories deep and not referenced from elsewhere! It also doesn't justify failing to proactively inform any of the clients making use of olm that these issues had been identified, and now anyone who does feel that this is inside their code's threat model has to rush to port to the new implementation after public disclosure.
Edit: but also if you're going to argue that it's unclear that these issues are remotely exploitable, it'd be helpful to discuss why - are there external constraints that ratelimit them such that the number of packets required is infeasible in any length of time? Is all the affected key material ephemeral and rotated before it's realistic to get a large enough sample? Just vibes?
> the author literally picked random projects from github tagged as matrix, without considering their prevalence or whether they are actually maintained etc.
I was very clear in my methodology: I grabbed everything tagged with that GitHub topic, and filtered out projects that were archived or marked as "old".
> meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago).
This is not an attitude that inspires confidence.
It's one thing to accidentally ship cryptography code with side-channels. It's another entirely to knowingly do so, and not fix it sooner.
> if you actually look at % of impacted clients, it’s tiny.
it's pretty much any client that has E2EE and is not Element. in my earlier quick look at Alpine Linux repos this included: Fluffychat, Nheko, gomuks, NeoChat, Chatty, weechat-matrix. then i already know that still didn't catch at least Cinny, which also is in Alpine, but includes libolm as wasm.
it's literally all "Featured clients" listed on Matrix.org except Element and Element X.
i'll put it another way. if anything other than New Vector is "tiny" and doesn't matter, is Matrix a "rich ecosystem"?
I usually keep myself out of HN discussions but some clients's issues are listed at https://github.com/NixOS/nixpkgs/pull/334638 from Nix's side, which includes Cinny, Fluffychat, nheko, which are the 3 non-Element "Featured clients" listed on Matrix.org.
if you actually look at % of impacted clients, it’s tiny.
meanwhile, it is very unclear that any sidechannel attack on a libolm based client is practical over the network (which is why we didn’t fix this years ago). After all, the limited primitives are commented on in the readme and https://github.com/matrix-org/olm/issues/3 since day 1.