-def aes_decrypt(key, nonce, payload):
+def aes_decrypt(_key, nonce, payload):
""" Use AES128 GCM with the given key and iv to decrypt the payload. """
- ciphertext = payload[:-16]
- mac = payload[-16:]
+ if len(_key) >= 32:
+ # XEP-0384
+ log.debug('XEP Compliant Key/Tag')
+ ciphertext = payload
+ key = _key[:16]
+ mac = _key[16:]
+ else:
+ # Legacy
+ log.debug('Legacy Key/Tag')
+ ciphertext = payload[:-16]
+ key = _key
+ mac = payload[-16:]
tom
I don't see where in XEP-0384 it says to use 32 byte keys instead of 16
tom
>4.5 Sending a message
In order to send a chat message, its <body> first has to be encrypted. The client MUST use fresh, randomly generated key/IV pairs with AES-128 in Galois/Counter Mode (GCM). The 16 bytes key and the GCM authentication tag (The tag SHOULD have at least 128 bit) are concatenated and for each intended recipient device, i.e. both own devices as well as devices associated with the contact, the result of this concatenation is encrypted using the corresponding long-standing SignalProtocol session.
bhaveshsguptahas left
bhaveshsguptahas joined
tom
where in https://xmpp.org/extensions/xep-0163.html does it specify how to set the access model?
tom
is it possible to send a pep with a specific access model?
tom
is it possible to send a pep with a specific access model?
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
wurstsalathas joined
bhaveshsguptahas left
bhaveshsguptahas joined
jrmuhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
Daniel
tom: you don't send it you publish it. https://wiki.xmpp.org/web/Tech_pages/OMEMO/publish_options
Daniel
> where in https://xmpp.org/extensions/xep-0163.html does it specify how to set the access model?
You'd have to look at xep60 as well
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
ajhas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
ralphm
Just for clarity here, XEP-0163 just highlights a particular subset of features of XEP-0060, and was designed primarily for so called 'extended presence' use cases. In the end though, it is just a profile of the protocols defined XEP-0060 with the pubsub service being someone's account.
ralphm
There are various cases where you want a pubsub node on someone's account, that does not fit XEP-0163's profile. This is perfectly ok, but would not be PEP.
lksjdflksjdfhas joined
ralphm
And it might be that server implementations do not (yet) fully support some of that.
lksjdflksjdfhas left
lksjdflksjdfhas joined
ralphm
E.g. up until version 1.2, XEP-0163 restricted nodes to just have one ('current') item.
ralphm
E.g. some uses of node-on-account allow non-owners to publish.
Kev
I think 'restricted' might be the wrong word there. "Only required" might be closer.
Kev
You were never prohibited from doing more than 163 required.
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
Zashhas joined
bhaveshsguptahas joined
ajhas joined
ralphm
No, what I mean is applications of PEP were supposed to only have one item per node, and otherwise it would not be PEP, but some other kind of node-on-account.
ralphm
But not any more since 1.2.
bhaveshsguptahas left
Zash
https://xmpp.org/extensions/xep-0222.html is the thing you wanna check out
tom
ok
tom
so with pep, Is it possible when I am publishing a PEP, can I publish it with a specific access model like open instead of of the default of presence, instead of querying the server for that pep node's property's and then applying the access node changes?
tom
because if I know a specific pep will always be open access, I could save a whole lot of programming and server transactions by sending the whole thing in one XML stanza
jonas’
tom, yes
tom
I am forking an OMEMO implementation. That's what I am using this for
tom, note that this is both a precondition and a set operation. So if the node exists already && has a different access model, you get a <conflict✎
jonas’
tom, note that this is both a precondition and a set operation. So if the node exists already && has a different access model, you get a <conflict/> error back. ✏
tom
thank you jonas and Daniel
jonas’
(shouldn’t be the case with OMEMO)
lovetox_
jonas’ why wouldnt it be the case with OMEMO?
Zash
Can happen if the node was created by a client that didn't do that
jonas’
lovetox_, I meant to say: you shouldn’t run into it with OMEMO
lovetox_
but you do, as publishing open access is neither described in the XEP
lovetox_
nor was it there since omemo started
lovetox_
all clients did at one point publish with whitelist
jonas’
lovetox_, right
jonas’
but then servers did mod_omemo_all_access
lovetox_
prosody did that, im not aware of any other impl
lovetox_
and only if the server admin is aware that such mod exists
jonas’
in ejabberd, you do that via config
jonas’
lovetox_, you don’t get a green tickmark on the compliance checker if you don’t
ralphm
lovetox_: but publish-options on the access model would help with that, no?
lovetox_
help with what?
jonas’
ralphm, lovetox_ was in response to my claim that you shouldn’t need to worry about <conflict/> responses with OMEMO✎
jonas’
ralphm, lovetox_ was in response to my claim that you shouldn’t need to worry about <conflict/> responses to using <publish-options/> with OMEMO ✏
ralphm
ah
Daniel
i guess the point is that your client needs to be prepared to deal with conflict
ralphm
well yes
Daniel
and not just regard publish-options as a set operation
ralphm
I think https://xmpp.org/extensions/xep-0060.html#publisher-publish-options is quite clear on this.
Daniel
well people don’t read xeps
ralphm
Of course. That's a recipe for failure, but hey, consenting adults.
tom
don't read XEPs?
tom
lol, are you veing serious or joking? I honestly can not tell :)
tom
>ralphm, lovetox_ was in response to my claim that you shouldn’t need to worry about <conflict/> responses to using <publish-options/> with OMEMO
So I guess either way I'm going to have to split this out into multiple stanzas and if statements if I want it implemented correctly. well that's fine because nobody else is going to fix this bug and I"m forking anyways