-
MSavoritias (fae,ve)
From what I understand there are 3 namespaces for omemo
-
MSavoritias (fae,ve)
- eu.siacs.conversations.axolotl - urn:xmpp:omemo:1 - urn:xmpp:omemo:2
-
MSavoritias (fae,ve)
is there any client that still uses the first one? to my knowledge all clients use omemo:1
-
MSavoritias (fae,ve)
I was told that dino uses the first one and doesnt use even omemo:1
-
edhelas
MSavoritias (fae,ve) I do
-
edhelas
https://github.com/movim/movim/blob/master/src/Moxl/Stanza/OMEMO.php#L27
-
MSavoritias (fae,ve)
why? also you dont advertise the second one at all?
-
edhelas
Because I didn't changed it yet, should I ?
-
MSavoritias (fae,ve)
thats what i am asking too. i thought all clients were using omemo:1 and were stuck on that because "reasons".
-
edhelas
Well, if we decide to all make the switch, I'm ready to change this
-
MSavoritias (fae,ve)
hmm. now i am also curious is that we are using omemo:1 but clients advertise the first one because compatibility
-
MSavoritias (fae,ve)
i would love for it to be at least this
-
MSavoritias (fae,ve)
well gajim devs at least says that they dont support omemo:1 at all
-
MSavoritias (fae,ve)
well this should a be warning at the top of xmpp.org not to use it for more than a toy. the "omemo" encryption that is. if thats the state on the other clients too
-
flow
as a rule of thumb, the any decentralized coordinated ecosystem moves slower than most expect
-
flow
there are various reasons for that, for example, software releases being coupled on distribution releases. so if you want maximum interoperability, you have to support an established namespaces for a relativly long period of time (think, for example, debian oldstable)
-
MSavoritias (fae,ve)
the problem is not that it moves slow
-
flow
which, in turn, further disincentivizes the adoption of new versions of the namespace
-
MSavoritias (fae,ve)
thats not my problem at least
-
MSavoritias (fae,ve)
my problem is that xmpp is known as the secure that uses encryption based on signal. and xmpp.org and the apps do nothing to make it obvious that it is very much not signal encryption
-
flow
the eu.*.axolotl namespace is using libsignal, so I am not sure where your assumption that its not using "signal encryption" steems from
-
MSavoritias (fae,ve)
if you go here https://xmpp.org/extensions/xep-0384.html#revision-history-v0.4.0
-
MSavoritias (fae,ve)
it says that at 0.4 it says > Incorporate the double ratchet protocol specification.
-
MSavoritias (fae,ve)
thats what i wanted a clarification on
-
flow
right, but it does not state that it did previously use something else. that's your interpretation of the text :)
-
flow
in short: omemo has always been used soemthing that more or less was directly derived from what signal does/did✎ -
flow
in short: omemo has always been used something that more or less was directly derived from what signal does/did ✏
-
MSavoritias (fae,ve)
well if we are using then omemo:1 why are we not using the namespace?
-
MSavoritias (fae,ve)
as per my original question. I was told omemo:1 is a different protocol
-
flow
sorry, I don't get the question, could you rephrase it?
-
MSavoritias (fae,ve)
right now we are using eu.siacs.conversations.axolotl
-
MSavoritias (fae,ve)
as the namespace
-
flow
yes, it is a different xmpp wire protocol, but the encryption scheme has always been signal'ly/double ratched/x3dh
-
MSavoritias (fae,ve)
is it this part?
-
MSavoritias (fae,ve)
Use XEP-0420: Stanza Content Encryption. Use AES256/CBC to encrypt SCE payload.
-
MSavoritias (fae,ve)
the different wire protocol
-
flow
those are some of the reasons the wire protocol was changed, yes
-
MSavoritias (fae,ve)
ah and also Use wrapping 'keys' element for key elements in 'header'.
-
MSavoritias (fae,ve)
ok
-
MSavoritias (fae,ve)
thanks for the clarifications. that was a scare ^^'
-
flow
yw
-
Guus
https://xmpp.org/about/myths/