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
prev 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