-
tom
What is going on here?
-
tom
-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.
-
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?
-
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
-
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.
-
ralphm
And it might be that server implementations do not (yet) fully support some of that.
-
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.
-
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.
-
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
-
jonas’
look into publish-options in XEP-0060
-
Daniel
have you read the tech pages link i posted?
-
jonas’
oh, yeah, also, what Daniel linked
-
tom
oh sorry, I didn't see the scrollback
-
tom
there's were publish options are
-
tom
AH there we go!
-
tom
<field var='pubsub#access_model'> <value>open</value> </field>
-
tom
so that's how you do it
-
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✎ -
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
-
Zash
Which people?
-
lovetox_
i think he meant you Zash 😃
-
tom
i meant jonas