jdev - 2019-09-04

  1. tom

    What is going on here?

  2. 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:]

  3. tom

    I don't see where in XEP-0384 it says to use 32 byte keys instead of 16

  4. 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.

  5. tom

    where in https://xmpp.org/extensions/xep-0163.html does it specify how to set the access model?

  6. tom

    is it possible to send a pep with a specific access model?

  7. tom

    is it possible to send a pep with a specific access model?

  8. Daniel

    tom: you don't send it you publish it. https://wiki.xmpp.org/web/Tech_pages/OMEMO/publish_options

  9. 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

  10. 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.

  11. 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.

  12. ralphm

    And it might be that server implementations do not (yet) fully support some of that.

  13. ralphm

    E.g. up until version 1.2, XEP-0163 restricted nodes to just have one ('current') item.

  14. ralphm

    E.g. some uses of node-on-account allow non-owners to publish.

  15. Kev

    I think 'restricted' might be the wrong word there. "Only required" might be closer.

  16. Kev

    You were never prohibited from doing more than 163 required.

  17. 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.

  18. ralphm

    But not any more since 1.2.

  19. Zash

    https://xmpp.org/extensions/xep-0222.html is the thing you wanna check out

  20. tom

    ok

  21. 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?

  22. 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

  23. jonas’

    tom, yes

  24. tom

    I am forking an OMEMO implementation. That's what I am using this for

  25. jonas’

    look into publish-options in XEP-0060

  26. Daniel

    have you read the tech pages link i posted?

  27. jonas’

    oh, yeah, also, what Daniel linked

  28. tom

    oh sorry, I didn't see the scrollback

  29. tom

    there's were publish options are

  30. tom

    AH there we go!

  31. tom

    <field var='pubsub#access_model'> <value>open</value> </field>

  32. tom

    so that's how you do it

  33. 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 ✎

  34. 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. ✏

  35. tom

    thank you jonas and Daniel

  36. jonas’

    (shouldn’t be the case with OMEMO)

  37. lovetox_

    jonas’ why wouldnt it be the case with OMEMO?

  38. Zash

    Can happen if the node was created by a client that didn't do that

  39. jonas’

    lovetox_, I meant to say: you shouldn’t run into it with OMEMO

  40. lovetox_

    but you do, as publishing open access is neither described in the XEP

  41. lovetox_

    nor was it there since omemo started

  42. lovetox_

    all clients did at one point publish with whitelist

  43. jonas’

    lovetox_, right

  44. jonas’

    but then servers did mod_omemo_all_access

  45. lovetox_

    prosody did that, im not aware of any other impl

  46. lovetox_

    and only if the server admin is aware that such mod exists

  47. jonas’

    in ejabberd, you do that via config

  48. jonas’

    lovetox_, you don’t get a green tickmark on the compliance checker if you don’t

  49. ralphm

    lovetox_: but publish-options on the access model would help with that, no?

  50. lovetox_

    help with what?

  51. jonas’

    ralphm, lovetox_ was in response to my claim that you shouldn’t need to worry about <conflict/> responses with OMEMO ✎

  52. 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 ✏

  53. ralphm

    ah

  54. Daniel

    i guess the point is that your client needs to be prepared to deal with conflict

  55. ralphm

    well yes

  56. Daniel

    and not just regard publish-options as a set operation

  57. ralphm

    I think https://xmpp.org/extensions/xep-0060.html#publisher-publish-options is quite clear on this.

  58. Daniel

    well people don’t read xeps

  59. ralphm

    Of course. That's a recipe for failure, but hey, consenting adults.

  60. tom

    don't read XEPs?

  61. tom

    lol, are you veing serious or joking? I honestly can not tell :)

  62. 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

  63. Zash

    Which people?

  64. lovetox_

    i think he meant you Zash 😃

  65. tom

    i meant jonas