I see your point, many thanks !

I see, thanks !

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

betterbird tray solution doesn’t work on wayland, given a bug on common code (affects both, Firefox, Thunderbird and derivatives). Just in case that’s one of the motivations of using betterbird. That by the way was the only feature that really made me look at betterbird, and as it didn’t work, I went back to TB. And if you’re wondering, birdtray doesn’t work on wayland, 😑.

Thunderbird is working on enabling exchange, and meanwhile you can combine it with TBSync plus its provider for exchange AcriveSync extensions. And given TB hadn’t care so far about tray, to at least avoid TB dying by mistake, you can also add Minimize on Close extension. Mail would still be IMap, so it’ll work as long as the outlook provider enables IMap support, but for the company I work it’s enabled. But such support is coming up on TB. Not sure if its solution would be 100% open source, but I hope it is, otherwise, I’m not sure if everyone will want to have a blob proprietary binary inside TB…

Fortunately there’s still Artix GNU+Linux :)

There are several patches under its patches source directory, and there are different sort of packages, one example is the sed patch to avoid including pocket in the build. The DRM widevine is not included either on the build, though it can be installed if you want it installed (probably there’s a patch for that somewhere).

But I no longer see removing binary blobs being advertised by Librewolf, it’s been a while since I don’t check on their site…

Not true, FF comes with few binary blobs which are removed from Librewolf. Also there are some things disabled entirely at build time, so they are removed from being an option. So it’s not just the settings, and it’s not plain re-branding. Some distros has gotten it wrong, believing that it’s just a matter of settings, but at least on the case of Librewolf and the Tor browser that’s not the case.

That hey depend on FF continuous development to exist is true, that doesn’t mean they just rebrand.

Haven’t tried halloy, but it sounds cool, I wish rust build with shared libs in mind, instead of everything link statically, but it sounds interesting, I’ll see how it is compared to srain which is my current choice…

srain, becuase of being modern gtk, because of being light on dependencies, because of being available on aur, and because I’d like it more (yes there are several things that are also a matter of taste) than the alternatives, :)

why toxic? Or better yet, define toxic.

mozilla private derivatives such as librewolf on the desktop and mull on android I just fine. So FF keeps being relevant as not being a derivative from chromium/chrome, it can remain apart from google disabling adds removing extensions.

So yes, FF is food to thrive, and so its derivatives will…

I has improved quite a bit. The phone app still requires navigating over its settings to get less battery consumption, and having ntfy or any other unifiedPush notification provider available in the phone. But with the default configs, you get Jami working at least. I tried it before, and I found before synchronization between devices was a mess. Currently it just works. I still find it hard on immediate/urgent calls or messages, which might not happen when you expect, but other than that it’s working.

On the desktop, the default configs are pretty sane.

And the best part, it’s being actively developed. And the UI is undergoing through lots of improvements. So if usability is your concern, it’s getting better, and each release improves over the prior one…

The audit is true, but at least Jami didn’t make up its own crypto lib, it uses standard already in use crypto stuff. To there’s a huge difference there.

BTW, they are actually re-writing stuff… But yes, they need more recent audits…

Have you read it’s github front page?

This is an experimental cryptographic network library. It has not been formally audited by an independent third party that specializes in cryptography or cryptanalysis. Use this library at your own risk.

BTW, if you look at its issues (including closed ones, which most probably aren’t really closed) you’ll find pretty interesting discussions about its crypto not being right. That said, I’m not sure what irungentoo brings to the picture…

At any rate, if you’re looking for distributed messaging, I’d look into Jami. It also uses DHT and something similar to torrents mechanism. Jami is my only option so far for distributed messaging. There’s also Briar, but I don’t like it for regular messaging, particularly on phones (too much battery usage), neither its underlying technology, but if it’s to your liking, then that’s another option for distributing messaging.

I do use “undetermined”. Thanks a lot. I’ll be asking lemmy.ml somwhere…

Because I have no clue what’s going on… I’m assuming you guys know better.

And no, they don’t seem to be old… There’s a recent post about dino I don’t see, I don’t see either a post about some messages not decrypted, another about dergchart, and finally another one about gajim…

If there’s nothing to comment here, that’s fine… I was just wondering.

IT might be, but librelinux for example really removes all binary blobs, although there’s some tooling around doing that, so new cases might be missed without human inspection, but they are careful about binary blobs… So from the whole spectrum of open source stuff, if you care about binary blobs, chances are better on the libre/free SW side.

Probably Guix, and GNU endorsed distributions. Binary blobs are not allowed on free/libre distributions, or not on their official repos. That said, most gnu + linux distributions don’t care about those. Most will take care, if they get to realize it, about distribution licenses, so if something has some sort of legal issue to be distributed, that will get purged from its repos most probably…

:)