end to end encryption

[karlitschek]

axolotl

[nsrosenqvist]

Is end-to-end encryption planned for both chat and video/audio?

[nickvergessen]

video/audio is already end-to-end encrypted

[sunjam]

I'm confused. If end to end encryption is already available, why is this feature and enhancement request for end to end encryption open?

[nickvergessen]

Well chat messages are still stored plaintext in the database.
But yeah, that has it's own issue at #1437

[4jNsY6fCVqZv]

@nickvergessen Does this mean that hosting telephone conferences with Spreed/ Nextcloud Talk are also encrypted end to end?
I thought you were using WebRTC like Jitsi, which end-to-end encryption can only do for audio/video calls in 1:1 conversations.
Unfortunately, your website & GitHub project README did not really help me to answer this question in such detail. That's why I now post directly to the issue on this topic.

[nickvergessen]

Well of course when you setup a SIP bridge for phone users, that is where the "end-to-end" ends. By default with the internal signaling backend audio/video calls (no matter if 1:1 or group) are end-to-end encrypted. But also with our High-Performance-Backend the end-to-end ends at it, because that is basically the client. Your system does not know to whome and how many participants the video is forwarded to by the high performance backend. That is one point where the better performance comes from.

[4jNsY6fCVqZv]

By default with the internal signaling backend audio/video calls (no matter if 1:1 or group) are end-to-end encrypted.

Would it be possible to explicitly mention E2EE for conferences in the following places?

• https://github.com/nextcloud/spreed#why-is-this-so-awesome

• https://nextcloud.com/talk

• https://github.com/nextcloud/talk-ios

• https://github.com/nextcloud/talk-android

I can't tell if your manuals explain this better.

[4jNsY6fCVqZv]

Well of course when you setup a SIP bridge for phone users, that is where the "end-to-end" ends.

Hmm, I don't understand this yet. It is about https://jitsi.org/jitsi-meet/ resp.
https://jitsi.org/jitsi-meet/ It's not about SIP.
The answer from the developers there is jitsi/jitsi-meet#409 (comment)
-> "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption. (As a matter of fact, unless you consistently vocally compare DTLS fingerprints with your peers, the same goes for one-to-one calls)"
How do you solve this?

[fancycode]

Both the SIP bridge and the WebRTC gateway of the HPB need access to the unencrypted media. The SIP bridge to perform audio mixing and the HBP to forward the streams to the different subscribers (for whom the media gets individually encrypted again).

[4jNsY6fCVqZv]

@fancycode Sorry, but when I read your statement, it makes the statement of @nickvergessen spongy again. Either it's encrypted end to end, or it's not. But if Nextcloud doesn't use WebRTC for the group/conference solution, the problem probably doesn't exist. Is that what @karlitschek meant by axolotl at the beginning?

[nickvergessen]

No, what @fancycode says is exactly what I said.
when you use the HPB its not peer to peer any more, but there is still end-to-end encryption between all peers and the HPB.

and without the HPB its always paar-to-peer and therefor end-to-end encrypted.

[nickvergessen]

And in which cases is the HPB mandatory?

It's not mandatory, you have to buy it and get a subscription for it. But it helps if you have more than a hand full of participants in your call, because otherwise you need to stram your own video 5 times and for most people the hardware + internet connection might come to a limit there at some point.

And how does axolotl play into this? Thought also the chats would be encrypted end to end if they use it.

Chat is currently not end-to-end encrypted, only the audio/video of calls are.

[4jNsY6fCVqZv]

It's not mandatory, you have to buy it and get a subscription for it

Okay, I get that. But I don't understand why the Jitsi people write, "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption."
That would only be true if I decided to use an additional HPB solution, wouldn't it? But not out of the box.

Chat is currently not end-to-end encrypted

Would it be if axolotl were implemented?

[nickvergessen]

Okay, I get that. But I don't understand why the Jitsi people write, "WebRTC today does not provide away of conducting multiparty conversations with end-to-end encryption."
That would only be true if I decided to use an additional HPB solution, wouldn't it? But not out of the box.

Exactly, I guess for better user experience and performance they have a SFU or MCU in place (our HPB is an SFU), and therefor it stops being end-to-end encrypted

Chat is currently not end-to-end encrypted

Would it be if axolotl were implemented?

Well any end-to-end encryption protocol for chats/instant messaging will do.

[4jNsY6fCVqZv]

Well any end-to-end encryption protocol for chats/instant messaging will do.

I'd rather continue the discussion on the right channel. see from #1437 (comment) on.

[4jNsY6fCVqZv]

Exactly, I guess for better user experience and performance they have a SFU or MCU in place (our HPB is an SFU), and therefor it stops being end-to-end encrypted

Would you please check again the clarity of your documents & texts in relation to this?
as suggested here #37 (comment)