Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <>
To: Dave Taht <>
Cc: "" <>
Subject: [Galene] End-to-end encryption [was: User management]
Date: Fri, 01 Oct 2021 16:20:43 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

> talking to a trusted videoconferencing server. I did rather like the
> insertable streams idea:

I like the idea of end-to-end encryption, but I feel that I'm not ready to
implement it yet.

Insertable streams gives you the ability to perform end-to-end encryption,
but it does not define the encryption format.  So you end up having to
design your own crypto, with all the dangers that this entails.  Before we
can use insertable streams, we need to have a clear specification of
a recommended encrypted format to use with it.  There is an IETF effort to
do that, but it's IETF, so it won't conclude before a few years.  (Last
time I checked, they were discussing the benefits of two approaches,
SFrame and Spacket, if memory serves, and there was no clear consensus yet.)

There are two other issues.  First, in order to do simulcast and keyframe
optimisation, Galene needs to look inside the packets.  Jitsi works around
the issue by not encrypting the first 8 octets of every packet, even one
that does not start a frame, but it's difficult to tell what amount of
information this leaks.  The proper solution to the issue is to have an
unencrypted header extension that contains the required information, but
that's only available with AV1 and not implemented yet (Chrome uses
a nonstandard format for AV1).

Second, simulcast for VP8 requires rewriting the packet contents, which is
obviously impossible if the data is encrypted.  This is solved with VP9,
but what it means is that you cannot have encrypted simulcast with VP8,
something has to give.

In short, Dave, I have given some serious thought to the issue of
end-to-end encryption, and I feel that it will need to wait a couple of
years before we can deploy it in production.

-- Juliusz

  reply	other threads:[~2021-10-01 14:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28 18:29 [Galene] User management Jeroen van Veen
2021-10-01 11:55 ` [Galene] " Juliusz Chroboczek
2021-10-01 14:05   ` Dave Taht
2021-10-01 14:20     ` Juliusz Chroboczek [this message]
2021-10-01 14:38       ` [Galene] Re: End-to-end encryption Michael Ströder
2021-10-01 15:24       ` [Galene] Re: End-to-end encryption [was: User management] Dave Taht
2021-10-03 19:15   ` [Galene] Re: User management Jeroen van Veen
2021-10-26 19:02     ` [Galene] Config branch [was: User management] Juliusz Chroboczek
2021-10-27 18:23       ` [Galene] " Jeroen van Veen
2021-10-29  9:10       ` Jeroen van Veen
2021-10-29 17:52         ` Juliusz Chroboczek
2021-10-30  8:22           ` Jeroen van Veen
2021-10-01 14:43 ` [Galene] Re: User management Dernat Rémy
2021-10-03 19:15   ` Jeroen van Veen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \
    --subject='Re: [Galene] End-to-end encryption [was: User management]' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox