jdev - 2025-01-03

To state the obvious: the very first line of Miernhoop's library's readme is "Do not use the code in this repository for anything serious" - I don't know about alternatives.

doge: as far as I'm aware, all remaining omemo implementations are based on libsignal or forks of that. Those are not documented terribly well and are not the most comfy to work with, but at least you have 5+ client codebases you can look at.

Regarding python-omemo: I wanted to port that to some low-level language since forever but well, I'm lazy ^^ I don't want to recommend ffi'ing Python, but if you want to try, I'm down to help. You could build a sync interface for the lib first to make it less awkward to ffi.

(maybe add a quick doap file to your project, Syndance?)

Guus: oh you are so right, I will do that, thanks

idk, at least mierehhoop's api seems more or less understandable from the code itself, as in I can roughly tell what's going on there at first skim, unlike the libsignal-* stuff. Seems much much comfier.

So the choice for me seems to be between using an obscure and undocumented C library vs a seemingly well documented python library, but the latter means bringing python into a non python project bloating it up multiple times in build complexity, size and startup time... I guess I'm gonna have to stick with the latter option or postpone tinkering with omemo altogether

However, I still want to make my client omemo ready, architecturally. Is my understanding correct that omemo doesn't tolerate message history holes? I.e. if your contact sends you messages a,b,c,d,e,f,g, and c,d,e are received by a different client while my client is offline, my client has to fetch all a,b,c,d,e,f,g for omemo to process, even if just e,f,g would be enough to fill up the screen?

Some apps(not xmpp) allow you to share keys through methods like QR codes, enabling you to use the same key on multiple devices. However, if you are very concerned about privacy, you should try to avoid logging in on too many devices ✏

doge: No, holes and incorrect message order are fine. You can fetch newest messages first.

hm. I thought omemo was supposed to change keys often so that even if your key is leaked your prev messages would be safe?

doge, it does, but IIRC it only advances the key when you reply with a message.

There are multiple layers of rotating keys that protect against different attack scenarios. For details check out the spec. In short, if an attacker gets a dump of your whole OMEMO state (= worst case for a one-time passive attack), they will be able to read new messages until sender and receiver "switch roles", i.e. until you reply. With only partial access to the state, they may be able to read only a single message (each message has a unique single-use key).

IIRC OMEMO uses a double-ratchet algorithm similar to signal's

here's a fun thing you can do: 1) make a backup of your computer 2) send some messages to people in OMEMO 3) restore from backup

this will break the sessions of the people you sent messages to previously, because your OMEMO key derivation would be "out-of-sync" with the other party's ✏

> here's a fun thing you can do: 1) make a backup of your computer 2) send some messages to people in OMEMO 3) restore from backup If someone sends a message to me in the time between the making of that backup and restoring it, will my OMEMO session break? ↺

(I'm not familiar with OMEMO, excuse the noob question)

almost all restore operations will break many of your sessions

except for the special case where you move your database to a new maschine so you can use it there

but i would not call this a backup