Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
From: Juliusz Chroboczek <jch@irif.fr>
To: Z0T <zot@mochela.it>
Cc: galene@lists.galene.org
Subject: [Galene] Re: End-to-end encryption, revisited (SFrame, client-side only)
Date: Fri, 23 Oct 2026 23:10:41 +0200	[thread overview]
Message-ID: <871p9g2kdq.wl-jch@irif.fr> (raw)
In-Reply-To: <179174903297.1218.62771834147183727@gauss>

> I'm writing about end-to-end encryption.

I agree with you, perhaps its time has come.  But if we do end-to-end
encryption, we need to do it right: there's no point implementing it if it
does not actually improve security.

> 1. a per-group setting, or simply a key present in the URL fragment (never
> sent to the server), enables encryption in the browser;

You need a key exchange protocol, and you need to rekey regularly (say,
every 20 minutes or so).  You need to rekey every time a client leaves
a meeting (so that a person who got kicked out cannot snoop on the
meeting).

The tricky bit is that with end-to-end encryption we are assuming the
server operator is mounting a passive attack, so the key exchange protocol
needs to be invulnerable to snooping.  I'm looking at the litterature, and
while there do exist some multi-party key exchange protocols, they're
extremely complex.  

> 2. frames are encrypted with SFrame (AES-256-GCM), keys derived from
> a shared group secret with HKDF;

No, the ability to rekey is essential.  If we cannot rekey, then we might
as well not implement it.

> 3. encrypted groups are restricted to VP9 or AV1, with whatever minimal
> unencrypted prefix Galène still needs for keyframe detection, documented
> explicitly;

I'm not sure that's necessary.  We should be able to signal keyframes
explicitly.

> - Would you accept such a contribution upstream (MIT, small, loaded lazily
> so it costs nothing to groups that don't use it), or would you prefer it
> to live as a separate client?

No promises either way, I'd need to see the code.

> - Which unencrypted bytes, if any, does the current server actually need
> from VP9 and AV1 frames?

See the file codecs.go.

> PS. To do this I proposed I'll use AI contribute.

We'll see how it goes.  However, given the AI contributions I've received
in the past (verbose, repetitive, and impossible to review), I'm not
optmistic.

Regards,

-- Juliusz

      parent reply	other threads:[~2026-10-23 21:10 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0eae8676-9575-4930-b0ee-d364251cf1d0@mochela.it>
2026-10-11 13:31 ` [Galene] End-to-end encryption, revisited (SFrame, client-side only) Z0T
     [not found] ` <179174903297.1218.62771834147183727@gauss>
2026-10-23 21:10   ` Juliusz Chroboczek [this message]

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.galene.org/postorius/lists/galene.lists.galene.org/

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

  git send-email \
    --in-reply-to=871p9g2kdq.wl-jch@irif.fr \
    --to=jch@irif.fr \
    --cc=galene@lists.galene.org \
    --cc=zot@mochela.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox