Hacker News Reader

Comment by Kye | Hacker News Reader

>> "3 of the 16 clients surveyed use the new vodozemac library. 10 still use libolm, and 3 don’t appear to implement end-to-end encryption at all."

This soesn't bode well for it as an option for secure messaging. Wouldn't be a problem if I didn't see people suggesting it as one.

View on HN

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.

> 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.

What the fuck.

projects that import the SDK /written by and (un)maintained by the matrix org/

e.g.: https://github.com/matrix-org/matrix-python-sdk (dependents doesn't work on this python project I guess)

or matrix-org/olm for JS

or matrix-org/matrix-js-sdk

or matrix-nio/matrix-nio (based on an old standard written by matrix, that matrix stayed compatible with rather than deprecating)

the inability to address the third issue (a security issue, no less) in 7 years is an impressive world record in incompetent messenger design

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.

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?

You SHIPPED CODE THAT YOU KNEW HAD A SIDE CHANNEL????? WHAT?

> 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"?

Reply on news.ycombinator.com