Gajim - 2016-12-26


  1. tuxayo hi :) Does anyone know if interoperability with the app Conversations is possible? Interoperability on the same account I mean. That is to say, begin a discussion on the phone and continue it on the desktop, all with history syncronisation.
  2. zak tuxayo: Yes it's possible. You can login several times at the same time.
  3. zak The features are called Message Carbons and Message Archive Management. It is required that the server and client support it though. Conversations does.
  4. juan tuxayo: You can also interoperate with other clients. Ej. gajim, conversejs
  5. tuxayo Is there a way to get history synced between devices? (is there a XEP that allows that?)
  6. zak tuxayo: see above: MAM
  7. tuxayo zak, oh sorry I missed this message. So it seems that Gajim supports it and also my server as it's conversations.im . Then the last piece of the puzzle for integration is sharing the OMEMO key. Otherwise it shouldn't even be possible to comunicate with someone else using OMEMO. Is that correct? I has anyone managed to use Gajim + Conversations with OMEMO?
  8. arune tuxayo: note that gajim does not sync messages from mam in the chat window, but in the history window
  9. arune Gajim does not sync muc mam messages
  10. arune But if both conversations and gajim is connected at the same time carbons is used and that works great
  11. arune tuxayo: omemo does not work like Pgp, you don't have the same key everywhere, instead each device has its own key
  12. linus Yeah, avoiding the need for key syncing is the whole reason omemo existd
  13. tuxayo arune, thanks I found the old messages.
  14. tuxayo arune, linus: I can only see the plain text ones (which is good, otherwise how would end to end encryption work) Is there a way to also see the OMEMO ones? (without E2EE)
  15. cippaciong tuxayo, you can use OMEMO in a multi-client setup as well. You just need to eneble OMEMO in each client and then trust your own device keys. There is no such thing as sharing OMEMO keys; Gajim will have its own key and Conversation will have another key.
  16. tuxayo cippaciong, it seems that the devices are trusting each other. But I've still haven't found a way to share OMEMO history. The only thing I've found is some obscure but reproducible bug which is still nice ^^ https://dev.gajim.org/gajim/gajim/issues/8493
  17. cippaciong Are you sending message to another contact using Gajim and Conversations or are trying to write from Gajim to Conversations and viceversa? I mean, are you chatting with yourself?
  18. cippaciong Because that's not a "supported" scenario iirc tuxayo
  19. tuxayo cippaciong, for the bug I was trying to chat with myself but it's not related to OMEMO. For history sharing, I used Conversations with another contact for several months. And now I'm trying to access the history from Gajim.
  20. cippaciong tuxayo, Have you been using OMEMO with that other contact?
  21. tuxayo cippaciong, yes
  22. cippaciong Then you can't get that history in Gajim
  23. cippaciong It's perfect forward secrecy :)
  24. cippaciong Messages sent back then were encrypted in a way such that they can be decrypted only using your conversations key or the one of your recipient.
  25. cippaciong You can get history in Gajim from now on, but not the previous one.
  26. tuxayo cippaciong, of course I would expect to have to do some operation (like a key exchange between devices) to see the history because E2EE and forward secrecy should prevent that from working out of the box. Well if it starts working from now on it's almost perfect
  27. SaltyBones Actually forward secrecy must prevent it from working at all
  28. SaltyBones That s what forward secrecy does
  29. SaltyBones But new messages can be sent to both devicea
  30. SaltyBones I'm actually not sure if and what MAM does in the context of perfect forward secrecy. It seem to be a contradiction. :)
  31. tuxayo SaltyBones, there could be a key exchange to do between devices so it could be done in theory.
  32. SaltyBones No :)
  33. tuxayo SaltyBones, I guess in stores encypted message and the device still has the key?
  34. SaltyBones The whole point of perfect forward secrecy is that you cannot decrypt your old messages
  35. SaltyBones So that if somebody gets your key they cannot decrypt stuff they have recorded in the past
  36. SaltyBones I mean you can decide you dont need that but that s what pfs is ;)
  37. tuxayo SaltyBones, if we add code that allows to export decryption keys from a device and import them into another device then it would be possible without violating FS. Is that correct?
  38. SaltyBones Well, pfs means that even if you export the keys you cannot decrypt old messages with them
  39. SaltyBones They way it works
  40. SaltyBones A bit simplified
  41. SaltyBones Is that you throw away the key after decrypting a message
  42. tuxayo SaltyBones, oh, this means that even the first device isn't actually decrypting the MAM messages, it just show it's local history?
  43. tuxayo I though it kept all the session keys locally
  44. SaltyBones Well, I'm not sure what it actually does but yes.
  45. SaltyBones Which of course also means that local history somewhat defeats the purpose of pfs. Because if somebody steals your key they probably got it from your phone and so they probably have the decrypted history anyway. :)
  46. tuxayo SaltyBones, is there a way to find out what is the actual behaviour? PFS + history: indeed, isn't there another use case for PFS
  47. SaltyBones I suppose to get the actual behavior you will have to check the implementation in your client. :)
  48. SaltyBones Another use-case...hm... I don't know. It makes sense in general but I suppose you would not keep really critical things in your history. It's an ephemeral thing, read and delete.
  49. SaltyBones For that you need pfs to cope with key compromise.
  50. SaltyBones But it may be over the top for your security needs.
  51. johannes So I've tried Gajim master on a recent linux. It dies instantly when pointed to an existing Gajim gtk2 profile folder. Which appears to be the same effect that can be seen on OSX.
  52. johannes On an fresh profile folder (-c something) it survives, even restarts and adding an account
  53. johannes However, the contact list rendering is defective as it is on mac and also throws Gtk-CRITICAL errors like there is no tomorrow
  54. tuxayo johannes, «It dies instantly» Any log in the terminal or in a file (if Gajim has a logfile)
  55. johannes already discussed & pastebinn'd, just as an update for lovetox
  56. johannes thanks though
  57. tuxayo SaltyBones, interesting I haven't though enough about PFS and that in most cases, we don't care about it and get rid of it by using history.
  58. SaltyBones Most of us dont need e2e crypto anyway but hey, got to start fighting the nsa somewhere, right? :)
  59. SaltyBones I would like an intermediate solution.
  60. SaltyBones Like shared history for a day or so. I dont usually use it much after that.
  61. SaltyBones But it helps with conversations when switching devices. :)
  62. lovetox johannes, thx, i know that the roster problem exists on all OS
  63. lovetox this is why i asked you to start it on mac with a separate profile
  64. lovetox not with your gtk2 profile
  65. lovetox it seems to affect specific accounts with specific rosters
  66. lovetox i cant reproduce it with my roster for example
  67. johannes Current gobject from brew has issues finding gi.repo so no testing there
  68. johannes Other than that: is there not a wiki and board feature in gitlab so one can track and store what is known and what not?
  69. johannes Also, something tells me that we need to properly isolate Gajim from the surrounding stuff, providing what is needed as frameworks in an app bundle
  70. lovetox what is the sorrounding stuff?
  71. lovetox you mean doing an installer?
  72. johannes The rest of the installed python path, whatever there is from brew etc.
  73. lovetox you can do this without problem with cx_freeze
  74. johannes Well Mac does not do installers, they do bundles
  75. lovetox whatever they do, cx_freeze supports it
  76. johannes Pyinstaller and py2app appear to be the recommended way for osx
  77. johannes Got a link to cx_freeze?
  78. lovetox google cx_freeze
  79. lovetox you can use the win32_setup.py in the repo
  80. lovetox as a starting point
  81. lovetox i think it will be not much different for mac
  82. lovetox and yes we have a wiki
  83. lovetox https://dev.gajim.org/gajim/gajim/wikis/help/GajimMacOSX
  84. lovetox you can edit this page with everything you find
  85. tuxayo SaltyBones, E2EE even without PFS is enough to defeat mass surveillance isn't it?
  86. johannes Information on what is known to be broken everywhere would be helpful on said wiki
  87. lovetox tuxayo
  88. lovetox if you dont want PFS, use GPG
  89. lovetox there is no reason to use OMEMO if you dont want PFS
  90. SaltyBones lovetox, is there a decent way to verify and trust keys with GPG?
  91. lovetox you mean in Gajim?
  92. lovetox verifing a key is nothing specific to omemo
  93. lovetox it just means exchanging keys over a another channel
  94. SaltyBones Only in theory it s not and I havent used it. :)
  95. SaltyBones But good to know. ;)
  96. SaltyBones tuxayo, depens on your threat model.
  97. SaltyBones Might be enough to encrypt c2s and s2s
  98. SaltyBones No crypto might be enough because of metadata...
  99. SaltyBones Many options :p
  100. tuxayo lovetox, don't need != don't want. Anyway why is OMEMO and related protocols (Signal) so much adopted by users lately compared to PGP? It's not because users want PFS, there are also things that allowed building easy and secure apps. SaltyBones, what are c2c and s2s? I can't find :-(
  101. SaltyBones client2server and server2server ie the server has the plaintext unlike e2e
  102. SaltyBones What signal did is it gave people an always on default
  103. SaltyBones And they use trust on first use and optional key verification
  104. SaltyBones Which at least in my peer group few people seem to do
  105. SaltyBones And if they did at somepoint "new phone" is always enough of a reason for switching keys
  106. SaltyBones So I guess what Signal really did is just use unauthenticated encryption. Meaning if you want to snoop you at least have to mitm and passive collection is no longer enough.
  107. SaltyBones And it gave people an easy way to be picky about keys should they want to...
  108. SaltyBones But really it should be combined with some key transparency system and something to hide metadata....but those are current research problems
  109. SaltyBones Blablabla :)
  110. tuxayo SaltyBones, thanks. C2c and s2s aren't enough against many mass surveillance treats. (PRISM) For metadata, we might have to end up using things like Bitmessage, Retroshare, Freenet.
  111. SaltyBones Hm...
  112. SaltyBones Depends on your servers of course.
  113. SaltyBones And the other stuff is imho still dubious.
  114. SaltyBones But yeah, interesting stuff. :)
  115. lovetox pfs is important for the use case of the average user, even if they dont know about it
  116. lovetox right now, with a encryption that has pfs, users dont have to think much about keys
  117. lovetox lost devices etc
  118. lovetox with pgp, a user should know that if he leaks his master key in someway, all his messages future or past can be forever decrypted
  119. lovetox as you can not expect the average non technical user to understand this or take precautions
  120. lovetox its not really viable as a mass used encryption
  121. SaltyBones I disagree
  122. SaltyBones Pfs is about the past
  123. SaltyBones But with the axolotl ratchet you do indeed also get future-secrecy
  124. lovetox its just, that as a company you can promise your users more security, even if the fuck up, you cant do this with pgp
  125. SaltyBones But still if you have multiple devices and lose one someone can read your messages in the future
  126. lovetox with pgp it will always be
  127. lovetox "you are secure IF you do that and that and that"
  128. lovetox no saltybones, not if the user marks his device as stolen..
  129. SaltyBones Sure but you have to do that :)
  130. SaltyBones And if the device had had a pgp key it would be the exact same process
  131. lovetox and even if he doesnt, you can implement something against "listener" devices
  132. SaltyBones I suppose you could but there isnt, is there?
  133. lovetox in signal there is i believe
  134. lovetox if a device not sends a message every X days
  135. lovetox its deleted from the conversation
  136. SaltyBones Huh....have to check that out :)
  137. lovetox but im not sure
  138. lovetox i know its something the omemo audit made aware
  139. lovetox that if you have a device that never sends a message
  140. lovetox the key on that device can be used to decrypt a lot of messages
  141. SaltyBones Got a link?
  142. lovetox https://conversations.im/omemo/audit.pdf
  143. SaltyBones Although it sounds like they might have fixed it by devices having to participate in the ratchet not actually sending messages to people.
  144. lovetox yeah heartbeat messages
  145. SaltyBones Thx
  146. lovetox but conversations doesnt have this until now
  147. SaltyBones Which doesnt really help you realize that there is a listening device. ;)
  148. lovetox no but you can differentiate between heartbeat messages and normal messages
  149. lovetox you could additionally say, if a device didnt send a real message for 5 days
  150. lovetox or something like this ..
  151. lovetox of course this affects then your history syncing
  152. lovetox but it could be a expert option
  153. lovetox to be honest i dont care much for that topic
  154. lovetox omemo as it is, is already plenty of security :)