Hey 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
MattJ
Have you see https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-developers too?✎
MattJ
Have you seen https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-developers too? ✏
MattJ
Not the standard, but it explains how they all fit together in an implementation
MattJ
Servers do nothing more than XEP-0215
MattJ
As 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
lovetox
when a server offers scram1, 256, 512
lovetox
is it his job to have the password hash for all of them?
lovetox
meaning if the server had previously only 1 and 256, he can just add 512
lovetox
because he does not have the hash for 512
Sam
You wouldn't be able to just add 512 if you don't have the hash; there is no good upgrade mechanism for scram
lovetox
Sam believe me people definitly wood
lovetox
because they have no clue what it is
lovetox
but thats my point, its not my problem as a client dev
lovetox
because someone bugged me about adding 512
Sam
oh, I'm sorry, I thought you were asking, maybe I'm missing context.
lovetox
and that means gajim now chooses 512 if available
Sam
512 isn't even a standardized thing yet, hopefully nothing changes before/if it ever becomes a standard
abdullahihas left
abdullahihas joined
lovetox
yes i know, but the one guy we all know about bugged all projects about it
lovetox
so they started adding it
qy
Neustradamus bugged everyone with a client, i think safe to ignore
Sam
Yes, I blocked him and didn't add it for that reason :)
lovetox
then users installed servers, without knowing what they did and activated it everywhere
Sam
Anyways, 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
Sam
But it will probably be okay.
lovetox
server manuals should put a big red sign on that setting
lovetox
describing in detail what it does to users
lovetox
like default is SCRAM-1
lovetox
and then a big red warning, dont activate anything else except you know what you are doing
nephelehas left
Sam
Yah, probably so
Zash
did we even document that?
lovetox
hm
lovetox
but there is a upgrade mechanism that comes to mind
xnamedhas joined
lovetox
switch the server to PLAIN, receive the pass, simulate the client hasing it and find the hash, afterwards rehash?
Sam
That 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)
lovetox
but thats easily solved
lovetox
user deletes acc from C and readds it
lovetox
but yeah thats bothersome
Sam
That seems like extremely bad UX for the user
lovetox
then the user can just change the pass :D
Sam
Yah, forcing a passsword reset is annoying but is one way
Sam
(assuming they have a client that can do that)
lovetox
hm
lovetox
but i can still get around C
lovetox
ah no
Matrix Traveler (bot)has left
homebeachhas left
homebeachhas joined
Matrix Traveler (bot)has joined
lovetox
it just will not send the pass damn
Zash
SASL2? SASL2!
stpeterhas left
kikuchiyohas left
Sam
Honestly, 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]
Zash
feels 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 Mauve
Sam, storing passwords in plain text is a really bad idea in my book.
Link Mauve
And if you store them hashed and do the PLAIN → SCRAM dance on the server it’ll take a huge lot of CPU power.
lovetox
yeah and there is no benefit or?
lovetox
you can just store them hashed
Link Mauve
But then you can only upgrade them on connection, which might not happen in a decade (or ever) for some users.
lovetox
ok, 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
Sam
Link Mauve: Obviously you should not store passwords in plain text, you should hash them. PLAIN says nothing about how it's stored.
Sam
It'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 Mauve
It’s a common misconception though, which might have prompted Neustradamus to go on his crusade.
qwestionhas left
Sam
Oh yah, definitely, sorry, bad example
Link Mauve
Sam, 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. :(
Sam
Yah, 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
MattJ
It's something I'll be working on this year
Sam
Extensible 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
Kev
Didn't Dave's SASL2 stuff cover this? Or was that only in principle?
MattJ
It does, I'm planning to implement it
Zash
Someone with motivation and free time really ought to look at {IBR,SASL,BIND}2 :tm:
antranigvhas joined
Kev
You 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.
Nils
MattJ: 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.
MattJ
Conversations only supports encrypted calls, so anything that can successfully call with Conversations is using encryption
Zash
I think Dino might have a thing showing some encryption details?
MattJ
I guess that's also why Conversations doesn't show encryption status - there is only one possibility :)
Zash
Can't you do calls without OMEMO then?
MattJ
Yes, the call encryption is unrelated to OMEMO, it uses temporary keys
Kevhas left
Kevhas joined
MattJ
So I mean, "no, you can do calls without OMEMO"
nephelehas left
nephelehas joined
Link Mauve
Conversations also created a mechanism for reusing an OMEMO session to validate the DTLS-SRTP key exchange IIRC.
MattJ
If you have an OMEMO session with the contact, it also signs them via that so they can be verified
Link Mauve
Right, that.
abdullahihas left
nephelehas left
nephelehas joined
Zash
Where 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
Nils
Okay 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?