NilsHey there, I have some questions for anybody who can help.
I'm having a really hard time figuring out how to have E2EE voice and video calls in XMPP.
(If this is not the place to discuss such things, let me know, as I have just joined the group.)
Anytime you have a call, is it just transport layer encryption or is end to end encryption baked into the base XEP that allows for calls?
Or is the "XEP-0320: Use of DTLS-SRTP in Jingle Sessions" needed?
Or is this XEP being implemented?
"Verify encrypted A/V calls with OMEMO" https://gist.github.com/iNPUTmice/aa4fc0aeea6ce5fb0e0fe04baca842cd
Also how does ZRTP factor into this? I have only found one client (ATalk on F-Droid) that explicitly states supporting ZRTP and only one (Conversations) that supports SRTP. My understanding is that these two protocols provide E2EE, not just transport layer. Is this correct? What is the advantage of ZRTP over SRTP? And is there any XMPP iOS client that supports any kind of end to end encryption for calls? I have not seen one, at least with clear documentation of that.
I also do not see much clear documentation of which XEP's are implemented on servers that relate to a/v calls.
Any information would be helpful, especially from those with links to documentation, sources of information, or server admins.
xnamedhas left
wydulazhas left
wydulazhas joined
wydulazhas left
MattJHave you see https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-developers too?✎
MattJHave you seen https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-developers too? ✏
MattJNot the standard, but it explains how they all fit together in an implementation
MattJServers do nothing more than XEP-0215
MattJAs for iOS, yes: Siskin supports encrypted calls
xnamedhas joined
PapaTutuWawahas joined
rq77has left
spectrumhas left
rafasaurushas left
kfvhas left
nephelehas joined
nephelehas left
nephelehas joined
lovetoxhas left
lovetoxhas joined
antranigvhas left
nephelehas left
antranigvhas joined
kfvhas joined
xnamedhas left
rafasaurushas joined
emushas left
xnamedhas joined
jgarthas joined
spectrumhas joined
syrupthinkerhas joined
lovetoxhas left
lovetoxhas joined
pulkomandyhas joined
kfvhas left
kfvhas joined
emushas joined
msavoritiashas left
msavoritiashas joined
rq77has joined
debaclehas joined
PapaTutuWawahas left
Alexhas left
msavoritiashas left
Laurahas left
Alexhas joined
Laurahas joined
thomaslewishas joined
thomaslewishas left
lovetoxhas left
thomaslewishas joined
thomaslewishas left
lovetoxhas joined
msavoritiashas joined
Samhas left
Samhas joined
Laurahas left
debaclehas left
Laurahas joined
stpeterhas joined
selurveduhas left
Wojtekhas left
Wojtekhas joined
lovetoxhas left
Beherithas joined
qwestionhas joined
xeckshas left
xeckshas joined
norayrhas joined
lovetoxhas joined
xeckshas left
xeckshas joined
marchas left
xeckshas left
xeckshas joined
nephelehas joined
lovetoxhas left
PapaTutuWawahas joined
lovetoxhas joined
nephelehas left
Wojtekhas left
nephelehas joined
Wojtekhas joined
nephelehas left
nephelehas joined
marchas joined
nephelehas left
lovetoxhas left
nephelehas joined
nephelehas left
rq77has left
marchas left
marchas joined
Laurahas left
lovetoxhas joined
lovetoxhas left
rafasaurushas left
lovetoxhas joined
rafasaurushas joined
rom1dephas left
rom1dephas joined
qwestionhas left
xnamedhas left
nephelehas joined
lovetoxwhen a server offers scram1, 256, 512
lovetoxis it his job to have the password hash for all of them?
lovetoxmeaning if the server had previously only 1 and 256, he can just add 512
lovetoxbecause he does not have the hash for 512
SamYou wouldn't be able to just add 512 if you don't have the hash; there is no good upgrade mechanism for scram
lovetoxSam believe me people definitly wood
lovetoxbecause they have no clue what it is
lovetoxbut thats my point, its not my problem as a client dev
lovetoxbecause someone bugged me about adding 512
Samoh, I'm sorry, I thought you were asking, maybe I'm missing context.
lovetoxand that means gajim now chooses 512 if available
Sam512 isn't even a standardized thing yet, hopefully nothing changes before/if it ever becomes a standard
abdullahihas left
abdullahihas joined
lovetoxyes i know, but the one guy we all know about bugged all projects about it
lovetoxso they started adding it
qyNeustradamus bugged everyone with a client, i think safe to ignore
SamYes, I blocked him and didn't add it for that reason :)
lovetoxthen users installed servers, without knowing what they did and activated it everywhere
SamAnyways, it's not likely to change, I'd just be worried that the working group would decide to add an upgrade mechanism or something then it would be incompatible with all the already deployed made up versions
SamBut it will probably be okay.
lovetoxserver manuals should put a big red sign on that setting
lovetoxdescribing in detail what it does to users
lovetoxlike default is SCRAM-1
lovetoxand then a big red warning, dont activate anything else except you know what you are doing
nephelehas left
SamYah, probably so
Zashdid we even document that?
lovetoxhm
lovetoxbut there is a upgrade mechanism that comes to mind
xnamedhas joined
lovetoxswitch the server to PLAIN, receive the pass, simulate the client hasing it and find the hash, afterwards rehash?
SamThat will be seen as a downgrade attack by some clients
Sam(Conversations in particular pins the mechanism and won't allow downgrade to an insecure one)
lovetoxbut thats easily solved
lovetoxuser deletes acc from C and readds it
lovetoxbut yeah thats bothersome
SamThat seems like extremely bad UX for the user
lovetoxthen the user can just change the pass :D
SamYah, forcing a passsword reset is annoying but is one way
Sam(assuming they have a client that can do that)
lovetoxhm
lovetoxbut i can still get around C
lovetoxah no
Matrix Traveler (bot)has left
homebeachhas left
homebeachhas joined
Matrix Traveler (bot)has joined
lovetoxit just will not send the pass damn
ZashSASL2? SASL2!
stpeterhas left
kikuchiyohas left
SamHonestly, while I do encourage the support for SCRAM which has applications where it's extremely useful, for general chat servers I'd just only allow PLAIN. It's probably safer against the kinds of real attacks that matter just because it's got hash agility, which is an *extremely* important property to have.
nephelehas joined
Sam[citation needed]
Zashfeels bad man
nephelehas left
nephelehas joined
COM8has joined
xnamedhas left
nephelehas left
nephelehas joined
rq77has joined
COM8has left
COM8has joined
COM8has left
kikuchiyohas joined
nephelehas left
nephelehas joined
COM8has joined
COM8has left
Laurahas joined
Link MauveSam, storing passwords in plain text is a really bad idea in my book.
Link MauveAnd if you store them hashed and do the PLAIN → SCRAM dance on the server it’ll take a huge lot of CPU power.
lovetoxyeah and there is no benefit or?
lovetoxyou can just store them hashed
Link MauveBut then you can only upgrade them on connection, which might not happen in a decade (or ever) for some users.
lovetoxok, after a decade, i return an error text that says: you didnt loggin for a decade, call me if you want your acc back
debaclehas joined
Matrix Traveler (bot)has left
homebeachhas left
homebeachhas joined
Matrix Traveler (bot)has joined
xnamedhas joined
antranigvhas left
abdullahihas left
abdullahihas joined
qwestionhas joined
rom1dephas left
antranigvhas joined
SamLink Mauve: Obviously you should not store passwords in plain text, you should hash them. PLAIN says nothing about how it's stored.
SamIt's not perfect, it's better than SCRAM. Most of the time hashes aren't broken completely right away, instead you get things like SHA-1 showing weaknesses for a while. At that point you can start the upgrade process for users as they log in. Eventually if it is broken entirely, then you issue a password reset email or whatever to any remaining users and disable the old hashes.
rom1dephas joined
qyhas left
Link Mauve(Not a reply to you, but) SHA-1 being broken means nothing to SCRAM-SHA-1, which is still perfectly fine.
Link MauveIt’s a common misconception though, which might have prompted Neustradamus to go on his crusade.
qwestionhas left
SamOh yah, definitely, sorry, bad example
Link MauveSam, we don’t have any mechanism for prompting a password reset atm, if we don’t know the email of a specific user they just get locked out. :(
SamYah, that's also a huge problem
kfvhas left
kfvhas joined
selurveduhas joined
antranigvhas left
qyhas joined
stpeterhas joined
nephelehas left
nephelehas joined
stpeterhas left
qwestionhas joined
MattJIt's something I'll be working on this year
SamExtensible IBR was originally going to cover this sort of thing, but I never saw much interest in adoption so maybe something else is needed that's simpler
Apollohas left
thomaslewishas joined
thomaslewishas left
PapaTutuWawahas left
KevDidn't Dave's SASL2 stuff cover this? Or was that only in principle?
MattJIt does, I'm planning to implement it
ZashSomeone with motivation and free time really ought to look at {IBR,SASL,BIND}2 :tm:
antranigvhas joined
KevYou have no idea how much I want to have the time (and/or one of the team's time) to properly look at stream startup things.
NilsMattJ: Thank you, just read that Github page.
So if I understand you right, servers implement XEP-0215 and SRTP encryption is handled on the client side?
Is there a way to know if a specific call I'm having is encrypted with SRTP? I know ATalk does this but I would love to see it in Conversations or Blabber.im.
And where did you find out that Siskin supports encrypted calls? Do you have a link?
Thanks so much for the info.
MattJConversations only supports encrypted calls, so anything that can successfully call with Conversations is using encryption
ZashI think Dino might have a thing showing some encryption details?
MattJI guess that's also why Conversations doesn't show encryption status - there is only one possibility :)
ZashCan't you do calls without OMEMO then?
MattJYes, the call encryption is unrelated to OMEMO, it uses temporary keys
Kevhas left
Kevhas joined
MattJSo I mean, "no, you can do calls without OMEMO"
nephelehas left
nephelehas joined
Link MauveConversations also created a mechanism for reusing an OMEMO session to validate the DTLS-SRTP key exchange IIRC.
MattJIf you have an OMEMO session with the contact, it also signs them via that so they can be verified
Link MauveRight, that.
abdullahihas left
nephelehas left
nephelehas joined
ZashWhere things (ZRTP things?) might show some fingerprints for manual verification otherwise
Kevhas left
Kevhas joined
pasdesushihas left
Kevhas left
xnamedhas left
pasdesushihas joined
xnamedhas joined
nephelehas left
qyhas left
abdullahihas joined
Yagizаhas left
Wojtekhas left
edhelashas left
Wojtekhas joined
edhelashas joined
qwestionhas left
qyhas joined
qwestionhas joined
Kevhas joined
Wojtekhas left
Beherithas left
msavoritiashas left
Alexhas left
Apollohas joined
thomaslewishas joined
thomaslewishas left
lovetoxhas left
Alexhas joined
Alexhas left
xeckshas left
qwestionhas left
antranigvhas left
antranigvhas joined
marc0shas left
marc0shas joined
syrupthinkerhas left
lovetoxhas joined
pasdesushihas left
goffihas left
larmahas left
antranigvhas left
antranigvhas joined
larmahas joined
thomaslewishas joined
thomaslewishas left
dezanthas left
wop001@no-bullchat.nethas joined
NilsOkay that's really good to know.
Do you know if Blabber.im as it is a fork of Conversations, does the same forcing encryption thing?
And just to be sure, you are talking about E2EE calls right?