XSF Discussion - 2019-02-27


  1. jubalh

    hi

  2. jubalh

    another question about OMEMO :) If I understand the XEP right one should encrypt the key and the GCM tag. Looking at dinos implementation it only seems to encrypt the key not the tag. Whats right?

  3. Syndace

    Interesting catch, I'm curious how dino is even able to talk to the other clients then

  4. Syndace

    Pretty sure encrypting the tag is the right way and all other clients do so as well

  5. flow

    jubalh, do you have a link/pointer to the relevant part of dino's implementation?

  6. jubalh

    Well, I'm not totally sure about it, but I think its this: https://github.com/dino/dino/blob/6de86c2733a26eb5034087ab25205ba1cba1e279/plugins/omemo/src/trust_manager.vala#L73

  7. jubalh

    Syndace, flow ^

  8. Syndace

    jubalh: Are you talking about "add_encryption_tag_to_message"?

  9. Syndace

    In line 153?

  10. flow

    which appears to be just the EME extension element (/tag)

  11. jubalh

    ahh so it does get encrypted?

  12. jubalh

    too many xeps to read :)

  13. jubalh

    Syndace, but thats not the gcm tag right?

  14. flow

    Syndace, no, it is a tag in the sense of XML

  15. Syndace

    Tag means XML-Tag there, it's just a little confusion

  16. flow

    err, jubalh ^

  17. jubalh

    so the gcm tag isnt encrypted if i see it right

  18. l

    jubalh, flow: This behavior changed in OMEMO. The original version would put the gcm tag to the ciphertext (this way it doesn't qualify for authenticity, but at least as a checksum), later the behavior was changed to encrypt the gcm tag to each device (so we get real authenticity as the per-device encryption is also signed). All clients support decrypting the old version, but for some time, some clients lacked support for decrypting the new version. Dino support decrypting both, but still encrypts using the old protocol. We should definitely change to the new version and there already is an issue for it https://github.com/dino/dino/issues/514 ;)

  19. jubalh

    l, awesome thanks for clarifying this!

  20. Syndace

    l, anywhere I can read up on the details? I have the same problem that my lib works with all clients but Dino.

  21. Wiktor

    Hello, I've got a question about "OTR has widely been replaced by OMEMO in the XMPP network and is recommended to be used instead." that is on https://wiki.xmpp.org/web/OTR It seems it's not clear what is recommended there and I think some draw the conclusion that it's OTR that is recommended (see: https://github.com/golang/go/issues/30141#issuecomment-467913000 ). I'm not a native speaker but what do you think about improving it so that the intent is clear?

  22. dwd

    "OTR is no longer the recommended way to wreck your user experience in return for some badly-understood security. Use OMEMO instead"?

  23. jonas’

    dwd, +1

  24. pep.

    that

  25. Wiktor

    dwd, 👍️. sounds unambiguous

  26. Wiktor

    just to show you the context: quote "in the XMPP world, the OTR protocol is still used as the standard secure messaging protocol" on https://github.com/golang/go/issues/30141#issuecomment-462031961

  27. Ge0rG

    [Redirect to:OMEMO]

  28. MattJ

    Wiktor, http://omemo.top/

  29. Wiktor

    I know I know, but apparently some people don't, I already commented on the GH ticket but the OTR guys took the quote from XMPP wiki as a recommendation *for* OTR

  30. Wiktor

    that's... I think... sub-optimal

  31. jonas’

    Wiktor, don’t you have +w on the wiki?

  32. Wiktor

    oh, wait, I do have it 🤔️ I hope it doesn't look weird if I say "even XMPP wiki recomends" and then write the recommendation myself :)

  33. jonas’

    hah

  34. jonas’

    just put dwds suggestion in it

  35. Wiktor

    👍️

  36. pep.

    That golang issue is missing the transport agnostic use-case, which is not inexistant. (even if that's what's mostly criticized of OTR in the XMPP community)

  37. Wiktor

    yeah, I was just annoyed at taking XMPP as an example of OTR being successfully deployed

  38. jonas’

    I still use and prefer OTR over OMEMO

  39. Zash

    I'm sure OTR is still in use in some circles

  40. Wiktor

    I don't mind their work, it would be completely stupid if I dictated how they should spend their time :)

  41. Zash

    Like those serrvers that mandate OTR

  42. Wiktor

    jonas’, why? genuinely curious

  43. MattJ

    Me too

  44. jonas’

    Wiktor, mine and my wife’s primary 1:1 client doesn’t support OMEMO in any usable way (i.e. without compiling some modules which aren’t even working)

  45. jonas’

    while OTR was painless to install and to use -- except with Conversations, but *that* issue has resolved itself nicely.

  46. Wiktor

    jonas’, what's that client that your wife is using?

  47. jonas’

    pidgin

  48. Wiktor

    got it

  49. jonas’

    in the past because multi-protocol, and now because "used to it"

  50. jonas’

    and why change a running system

  51. jonas’

    in a single-client setup, it’s very much "good enough"

  52. jonas’

    especially when you’re still from the age of ICQ, so you know that a sudden reconnect causes lost messages and you need to negotiate that in-band

  53. Wiktor

    no probs with that, I understand legacy solutions, heck, I'm still using some ;)

  54. jonas’

    I personally still use pidgin to keep the pain levels high enough to motivate me to work on my own client side stuff

  55. Wiktor

    haha, good idea 👍️