On the Monal and OMEMO story that is making its rounds: The AES-GCM spec recommends 12-byte IVs. The OMEMO XEP doesn’t say anything in that regard. In the beginning all OMEMO implementations used 16 bytes b/c developers only read OMEMO and didn’t know about the GCM recommendation

7:53 AM · Feb 16, 2020

4
0
2
10
In late 2018 developers realized that using 12 bytes would be a bit better because some libraries don’t implement the 16 to 12 byte hashing mechanism. How do you migrate an ecosystem of half a dozen clients from 16 to 12? Implement support for reading 12 bytes first and then, …
1
0
0
3
… once every implementation supports reading 16 and 12 start to send 12 bytes. We notified all known projects and even submitted patches for some. Most projects implemented 12 byte read support fairly quickly. Except @ChatSecure. Then, while waiting for CS, we forgot about it.
3
0
0
4
Now @Monal is going to break that migration strategy with two mistakes: Read only 12 bytes (and not the 'old' 16); and start sending 12 before everyone (most importantly ChatSecure) has implement read support for 12. As a result most clients will understand what Monal is sending,
2
0
0
2
but almost nobody will be able to send to Monal. Not even older versions of Monal! This forces Conversations into the dilemma of having to decide if it wants to send messages that ChatSecure understands or messages that Monal understands.
1
0
0
3
While Conversations would be able to ship 12-byte-sending fairly quickly (The code exists; it's just a compile time flag) the desktop clients with their Debian packages won’t be able to ship over night. If Monal would keep support for reading 16 those problems could be minimized.
2
0
0
3
Replying to @iNPUTmice
Thanks for that detailed clarification. As a user and server operator, but not developer, I've appreciate if things like that would be communicated when they come up and via channels that are dedicated to users (e.g. website, mastodon, twitter,...) to avoid misunderstandings
0
0
0
2
Replying to @iNPUTmice
As general rule, any kind of agility in cryptography is hard, but this might have been easier with a bit of discovery. We need to work on offline discovery too make this easier.
0
0
0
0
This Tweet was deleted by the Tweet author.
AES-GCM internally uses 96. If you provide anything but 96 it needs to be hashed down to 96 first. Some libraries lack support for that step. (There are security considerations for IVs other that 96 bits if you reuse keys; which we don’t; but might explain the missing support)
0
0
0
2