12 byte IV for outgoing messages #24
Comments
12-byte IVs (gkdr#24)
|
@gkdr: After Dino 0.2.0 released the 12th November 2020, it is time to see for libomemo, no? @craftyguy: What do you think? Linked to: |
|
It seems to work, I haven't done a ton of testing, but I've been able to communicate with folks who are on Conversations/Android. |
|
one of the last comments in the thread you linked says that the IV size will not be enforced for the omemo version this implements. what is the exact problem? which clients are incompatible leaving it as it is? which clients are incompatible after the change? |
|
@gkdr: It is neccessary to have this in all OMEMO clients based on XEP-0384 v0.3.0 before the major changes in v0.4.0+. It is been solved in Dino 0.2.0, few days ago. The last historical XMPP client which does not support the good value is Pidgin with this libomemo... |
|
@Neustradamus can you show me where the IV length is specified? the thread you linked seems says the opposite - no IV length should be enforced. do you know about chatsecure specifically? |
|
After reading through the xeps PR I'm a bit confused. |
|
Not sure how XEP versioning works, but I doubt there will be 0.3.1 clarifying the IV wording, and 0.4 (omemo:1) switched to a different encryption mode and key size altogether. |
|
@Yuubi-san 96 bits = 12 bytes 🙂 the 16 bytes were set by Conversations in the beginning and everyone just tried to be compatible as the spec basically did not exist. it's probably some weird android default thing. aside from that, i completely agree - staying 'on-spec' is no use if it's incompatible with major clients, especially if this is a thing that's not even defined to begin with. what i want to know, and am trying desperately to get out of @Neustradamus who is pushing this change - if I change it to 12 byte IVs, which clients break? so far i didn't get a straight answer is all. or is the list supposed to mean that all of them are fine with it? changing the constant is not a big deal, i just want to make sure nothing breaks. ps: iirc i just get the length of the IV i was given and set that as the size to give to the crypto lib, so this lib is compatible with any received length. (this assumes the lib will tell me if the length is invalid.) the sent out IVs are the only issue. |
Of course, that's what I meant, but failed to specify the units. :)
Could be the API weirdness, yeah. Despite the implementation special-casing 12 as the simple code path: https://android.googlesource.com/platform/external/bouncycastle/+/d3dea7fcf0e206859d8df1af01523f40d8008195/bcprov/src/main/java/org/bouncycastle/crypto/modes/GCMBlockCipher.java#150
I think so, but see below.
Sooo... then it seems you're already doing what others do. I dont think anyone is sending 12-byte IVs as of now. I could be wrong, though, but then I'd say it's their fault for rushing the transition (if it'll happen at all at some point). BTW, are you also handling (the fragment part of) the aesgcm URI scheme in this lib? |
|
Hi all, sorry for the delay, I was blocked by GitHub. Now the patch is in:
What's next? @languitar: Can you add this patch in Arch? @gkdr: Not possible to merge it directly, better than a patch, no? Note: Debian 11 freeze is soon, it will be nice to have a best version before Debian 12 in 2023. |
|
@Yuubi-san monal did only 12 byte IV because that's the only thing the ios standard lib supports afaik. that triggered it all. so this is not compatible with monal, but i don't know what other compatibilities this lib will lose. @Neustradamus i'm not saying it's impossible to merge it, i just don't have the time to hunt down omemo implementation specifics. will clients break if i do this? @craftyguy and @fortysixandtwo: what made you patch that? i just want to know why to make this change is all, i'm not against it 🙂 |
|
@gkdr: You do not understand, currently, libomemo is broken without this patch. It is solved in Alpine and Debian ;) |
|
Hey @gkdr, I would be happier with a patch supporting both 12 and 16 byte IVs. See also: Having this said what made me patch was the great number of other clients which apparently And btw the new XEP 0384 mandates 16byte IVs. |
|
@gkdr My suggestion would be to send 12-byte IV when aiming for compatibility with "siacs" OMEMO (XEP-0384 0.3.0). Large majority of clients support receiving 12-byte IV (all except not-latest version of some clients AFAIK) and it is required for Monal. All other major clients can receive 16-byte IV, which is why you don't see significant issues when sending 16-byte. When receiving, you can virtually allow every size your library supports - which seems to be what you are already doing. Most clients send 12-byte IV but some send 16-byte IV. The IV is not required for any security property of OMEMO (as OMEMO never uses the same key for AES encryption), using 12- or 16-byte IV thus doesn't matter at all (except for compatibility with Monal). @fortysixandtwo The OMEMO specified in XEP-0384 0.4 and later versions is largely incompatible with "siacs" OMEMO except that keys/trust can be transferred and, as of today and as far as I am aware, no client implements it in production. The IVs used there are not relevant for "siacs" OMEMO (also they are used as an input for AES-CBC which needs to be 16 byte whereas AES-GCM as used in "siacs" OMEMO can handle any size of IV). |
|
@mar-v-in Huge thanks for clarifying this! Now it all starts to make sense. |
|
Note: I have done same for libpurple-omemo-plugin: |
I've just pushed that patch. Any chance to get a new release here? |
|
@languitar: Thanks :) |
|
@leahneukirchen: Thanks :) Now it is done in VoidLinux too: |
|
@Neustradamus yes, and it was the Monal client's choice to be incompatible to the other clients (even though i kinda understand their reasoning). no where does it say that sending a 12 byte IV is "correct". please stop pushing downstream changes, it makes the whole situation even more confusing. |
gkdr
changed the title
|
For the record, I packaged lurch for Gentoo and refused to patch downstream prior to better understanding the situation myself and a decision made upstream. |
|
@Neustradamus: just to be clear: I appreciate your energy and effort in general, thanks for that. As far as I can see, the issue felt through the cracks - that can happen, especially as the initial report and the PR (#27) were - well, not very informative or obviously actionable. Thus the argument of "this has been known for month" is a bit mood - the second post is 17 days ago and 15 days ago it caught @gkdr s attention. So, again, thanks for the initiative, but for the next time: please first try to catch upstream attention more aggressively before contacting package maintainers. If upstream is inactive and not reachable for a long time - well, in case of a crypto library that would scream for a fork or drop altogether. So really, downstream patches should only be used as a last resort for dead projects that might still be in use - IMO :) |
The XEP-0384 0.3.0 does not specify the "IV" value and the 0.3.1 version has been missing before the 0.4.0 version. All OMEMO 0.3.0 clients must send with 12-byte instead 16-byte IV. This PR solves this problem, linked to gkdr#24.
|
@gkdr: I have updated my description here and my PR like your have requested me. |
|
i didn't mean to say that i don't understand why someone would patch this downstream - if monal compatibility is important, it's certainly valid. thank you guys for maintaining this. @Neustradamus thanks for putting effort into this as well. i didn't mean to be dismissive, please just be careful with words like "correct" or "incorrect" in the future unless you have very good arguments, or be prepared for discussions 🙂 |
The XEP-0384 0.3.0 does not specify the "IV" value and the 0.3.1 version has been missing before the 0.4.0 version. All OMEMO 0.3.0 clients must send with 12-byte instead 16-byte IV. This PR solves this problem, linked to #24.
|
merged the pr, so i'm closing this. |
|
@gkdr: Thanks for merging in "dev", in "master" and for 0.7.0 build. @ all: There is a 0.7.0 release: |
Thanks! I'm subscribed to "releases" here, but didn't get a notification from GitHub about 0.7.0 because it's not a "real release" from GitHub's point of view - i.e. @gkdr didn't clicked a button "make a release" from 0.7.0 tag. To me this GitHub's behaviour looks quite annoying, but there are ways to automate this (like using GitHub Actions to make releases from some tags). |
|
@powerman oh thanks, that's good to know. i just created a real release. |
This fixes communication with users of iOS Monal Related: gkdr/libomemo#24 Signed-off-by: Sebastian Pipping <sping@gentoo.org> Package-Manager: Portage-3.0.0, Repoman-2.3.23
|
I have updated the copy of libomemo bundled by lurch in Gentoo now. It would be nice, if these two projects would communicate using shared libraries and be more independent. The current approach of linking against .a files is rather unusual and not ideal. Thanks in advance. |
|
@hartwork debian uses libomemo as shared lib. https://salsa.debian.org/DebianOnMobile-team/libomemo / https://salsa.debian.org/DebianOnMobile-team/purple-lurch |
Hi @agx I checked the two links: The only shared lib I see is lurch itself. Also, downstream patching is ideally zero so shared libs is something that is done once and for all upstream, ideally. Am I missing something? |
|
@hartwork Relevant upstream PRs: https://github.com/gkdr/lurch/pull/151/files |
|
@fortysixandtwo those are probably all nice, but I'd need things on |
|
@hartwork i divided the project into submodules just for development and clear responsibilities, and to be honest i never thought any of this would end up in package repos (or even used at all). since git submodules are not ideal for packaging and github also ignores them for the autogenerated tarballs i also provide a tarball of all the code bundled together. however, no one seems to use those. which in turn influenced me to not release the plugin itself for every submodule change, but whatever. also, for a long time the core component @fortysixandtwo i am terribly sorry. with the little time i can put into this right now, i just keep losing track of things. plus github deleted old notifications on me by itself or something? i am logged in almost every day though since i use this account at my workplace, so please don't hesitate to ping me if something else comes up. thanks for your contribution. (@hartwork i don't get notified from reacts. is there a way to turn that on?) (i usually used to work on this during my commute by train, but can probably imagine that's not happening currently 😬 ) |
|
Don't worry about it ;) |
|
@gkpr I don't think GitHub reaction notification is possible. It would probably very noisy. |
|
@gkdr Also it is not hard to add package to vcpkg when needed. BTW, in MXE even libomemo package exist. But it should be updated though. |
|
@tehnick: About libomemo and MXE, there is a ticket: |
|
Some comments are hidden by default, I recall to all that:
Alpine, Debian (+ PureOS), Gentoo, Alt Linux are already perfect. Some OS have only one package instead of 3:
Some OS maintainers have not updated packages yet -> Compatibility problem, time to update. In more, there is a problem with the lurch package name, never same name: |
Please note that before bothj axc and libomemo start building shared libraries (.so files) — libomemo seems done as of 0.7.0 but axc seems todo as of gkdr/axc#17 — , providing three packages is of little extra value because you'd still need to recompile lurch when one of the other two updated because of static linking. So that needs to be improved upstream before it can really improve downstream. (I'm happy to join working on that upstream if a tight feedback loop is guaranteed.)
Distributions have different naming schemes plus at least some follow the upstream naming as far as technically possible. The upstream name is "lurch" and not "pidgin-lurch" hence I went for "lurch" in "Gentoo" initially. Name |
The XEP-0384 0.3.0 does not specify the "IV" value and the 0.3.1 version has been missing before the 0.4.0 version.
All OMEMO 0.3.0 clients must send with 12-byte instead 16-byte IV.
This issues is solved in #27.
More informations:
Already good:
Linked to:
The text was updated successfully, but these errors were encountered: