tuxayohi :) 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.
zaktuxayo: Yes it's possible. You can login several times at the same time.
zakThe features are called Message Carbons and Message Archive Management. It is required that the server and client support it though. Conversations does.
juantuxayo: You can also interoperate with other clients. Ej. gajim, conversejs
tuxayoIs there a way to get history synced between devices? (is there a XEP that allows that?)
zaktuxayo: see above: MAM
tuxayozak, 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?
arunetuxayo: note that gajim does not sync messages from mam in the chat window, but in the history window
aruneGajim does not sync muc mam messages
aruneBut if both conversations and gajim is connected at the same time carbons is used and that works great
arunetuxayo: omemo does not work like Pgp, you don't have the same key everywhere, instead each device has its own key
linusYeah, avoiding the need for key syncing is the whole reason omemo existd
tuxayoarune, thanks I found the old messages.
tuxayoarune, 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)
cippaciongtuxayo, 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.
tuxayocippaciong, 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
cippaciongAre 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?
cippaciongBecause that's not a "supported" scenario iirc tuxayo
tuxayocippaciong, 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.
cippaciongtuxayo, Have you been using OMEMO with that other contact?
tuxayocippaciong, yes
cippaciongThen you can't get that history in Gajim
cippaciongIt's perfect forward secrecy :)
cippaciongMessages 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.
cippaciongYou can get history in Gajim from now on, but not the previous one.
tuxayocippaciong, 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
SaltyBonesActually forward secrecy must prevent it from working at all
SaltyBonesThat s what forward secrecy does
SaltyBonesBut new messages can be sent to both devicea
SaltyBonesI'm actually not sure if and what MAM does in the context of perfect forward secrecy. It seem to be a contradiction. :)
tuxayoSaltyBones, there could be a key exchange to do between devices so it could be done in theory.
SaltyBonesNo :)
tuxayoSaltyBones, I guess in stores encypted message and the device still has the key?
SaltyBonesThe whole point of perfect forward secrecy is that you cannot decrypt your old messages
SaltyBonesSo that if somebody gets your key they cannot decrypt stuff they have recorded in the past
SaltyBonesI mean you can decide you dont need that but that s what pfs is ;)
tuxayoSaltyBones, 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?
SaltyBonesWell, pfs means that even if you export the keys you cannot decrypt old messages with them
SaltyBonesThey way it works
SaltyBonesA bit simplified
SaltyBonesIs that you throw away the key after decrypting a message
tuxayoSaltyBones, oh, this means that even the first device isn't actually decrypting the MAM messages, it just show it's local history?
tuxayoI though it kept all the session keys locally
SaltyBonesWell, I'm not sure what it actually does but yes.
SaltyBonesWhich 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. :)
tuxayoSaltyBones, is there a way to find out what is the actual behaviour?
PFS + history: indeed, isn't there another use case for PFS
SaltyBonesI suppose to get the actual behavior you will have to check the implementation in your client. :)
SaltyBonesAnother 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.
SaltyBonesFor that you need pfs to cope with key compromise.
SaltyBonesBut it may be over the top for your security needs.
johannesSo 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.
johannesOn an fresh profile folder (-c something) it survives, even restarts and adding an account
johannesHowever, the contact list rendering is defective as it is on mac and also throws Gtk-CRITICAL errors like there is no tomorrow
tuxayojohannes, «It dies instantly» Any log in the terminal or in a file (if Gajim has a logfile)
johannesalready discussed & pastebinn'd, just as an update for lovetox
johannesthanks though
tuxayoSaltyBones, 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.
SaltyBonesMost of us dont need e2e crypto anyway but hey, got to start fighting the nsa somewhere, right? :)
SaltyBonesI would like an intermediate solution.
SaltyBonesLike shared history for a day or so. I dont usually use it much after that.
SaltyBonesBut it helps with conversations when switching devices. :)
lovetoxjohannes, thx, i know that the roster problem exists on all OS
lovetoxthis is why i asked you to start it on mac with a separate profile
lovetoxnot with your gtk2 profile
lovetoxit seems to affect specific accounts with specific rosters
lovetoxi cant reproduce it with my roster for example
johannesCurrent gobject from brew has issues finding gi.repo so no testing there
johannesOther than that: is there not a wiki and board feature in gitlab so one can track and store what is known and what not?
johannesAlso, something tells me that we need to properly isolate Gajim from the surrounding stuff, providing what is needed as frameworks in an app bundle
lovetoxwhat is the sorrounding stuff?
lovetoxyou mean doing an installer?
johannesThe rest of the installed python path, whatever there is from brew etc.
lovetoxyou can do this without problem with cx_freeze
johannesWell Mac does not do installers, they do bundles
lovetoxwhatever they do, cx_freeze supports it
johannesPyinstaller and py2app appear to be the recommended way for osx
johannesGot a link to cx_freeze?
lovetoxgoogle cx_freeze
lovetoxyou can use the win32_setup.py in the repo
lovetoxas a starting point
lovetoxi think it will be not much different for mac
lovetoxyou can edit this page with everything you find
tuxayoSaltyBones, E2EE even without PFS is enough to defeat mass surveillance isn't it?
johannesInformation on what is known to be broken everywhere would be helpful on said wiki
lovetoxtuxayo
lovetoxif you dont want PFS, use GPG
lovetoxthere is no reason to use OMEMO if you dont want PFS
SaltyBoneslovetox, is there a decent way to verify and trust keys with GPG?
lovetoxyou mean in Gajim?
lovetoxverifing a key is nothing specific to omemo
lovetoxit just means exchanging keys over a another channel
SaltyBonesOnly in theory it s not and I havent used it. :)
SaltyBonesBut good to know. ;)
SaltyBonestuxayo, depens on your threat model.
SaltyBonesMight be enough to encrypt c2s and s2s
SaltyBonesNo crypto might be enough because of metadata...
SaltyBonesMany options :p
tuxayolovetox, 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 :-(
SaltyBonesclient2server and server2server ie the server has the plaintext unlike e2e
SaltyBonesWhat signal did is it gave people an always on default
SaltyBonesAnd they use trust on first use and optional key verification
SaltyBonesWhich at least in my peer group few people seem to do
SaltyBonesAnd if they did at somepoint "new phone" is always enough of a reason for switching keys
SaltyBonesSo 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.
SaltyBonesAnd it gave people an easy way to be picky about keys should they want to...
SaltyBonesBut really it should be combined with some key transparency system and something to hide metadata....but those are current research problems
SaltyBonesBlablabla :)
tuxayoSaltyBones, 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.
SaltyBonesHm...
SaltyBonesDepends on your servers of course.
SaltyBonesAnd the other stuff is imho still dubious.
SaltyBonesBut yeah, interesting stuff. :)
lovetoxpfs is important for the use case of the average user, even if they dont know about it
lovetoxright now, with a encryption that has pfs, users dont have to think much about keys
lovetoxlost devices etc
lovetoxwith pgp, a user should know that if he leaks his master key in someway, all his messages future or past can be forever decrypted
lovetoxas you can not expect the average non technical user to understand this or take precautions
lovetoxits not really viable as a mass used encryption
SaltyBonesI disagree
SaltyBonesPfs is about the past
SaltyBonesBut with the axolotl ratchet you do indeed also get future-secrecy
lovetoxits just, that as a company you can promise your users more security, even if the fuck up, you cant do this with pgp
SaltyBonesBut still if you have multiple devices and lose one someone can read your messages in the future
lovetoxwith pgp it will always be
lovetox"you are secure IF you do that and that and that"
lovetoxno saltybones, not if the user marks his device as stolen..
SaltyBonesSure but you have to do that :)
SaltyBonesAnd if the device had had a pgp key it would be the exact same process
lovetoxand even if he doesnt, you can implement something against "listener" devices
SaltyBonesI suppose you could but there isnt, is there?
lovetoxin signal there is i believe
lovetoxif a device not sends a message every X days
lovetoxits deleted from the conversation
SaltyBonesHuh....have to check that out :)
lovetoxbut im not sure
lovetoxi know its something the omemo audit made aware
lovetoxthat if you have a device that never sends a message
lovetoxthe key on that device can be used to decrypt a lot of messages
SaltyBonesGot a link?
lovetoxhttps://conversations.im/omemo/audit.pdf
SaltyBonesAlthough it sounds like they might have fixed it by devices having to participate in the ratchet not actually sending messages to people.
lovetoxyeah heartbeat messages
SaltyBonesThx
lovetoxbut conversations doesnt have this until now
SaltyBonesWhich doesnt really help you realize that there is a listening device. ;)
lovetoxno but you can differentiate between heartbeat messages and normal messages
lovetoxyou could additionally say, if a device didnt send a real message for 5 days
lovetoxor something like this ..
lovetoxof course this affects then your history syncing
lovetoxbut it could be a expert option
lovetoxto be honest i dont care much for that topic
lovetoxomemo as it is, is already plenty of security :)