[Galene] End-to-end encryption, revisited (SFrame, client-side only)

[Galene] End-to-end encryption, revisited (SFrame, client-side only)

[Z0T]

Hello Juliusz


I run Galène 1.2.1 for a small, volunteer-run mail and messaging service 
(mochela.it, three nodes in three EU countries, everything free software 
and deployed with Ansible). Thank you for Galène.

I'm writing about end-to-end encryption. I read your message of 1 
October 2021 in the thread "End-to-end encryption [was: User 
management]", where you listed three obstacles: no standard frame 
format, Galène needing to read packets for keyframe detection and 
simulcast, and VP8 simulcast being impossible with encrypted payloads. 
You concluded it would need a couple of years. Five years later, some of 
this has moved:

- SFrame is now RFC 9605 (2024), so the frame format no longer has to be 
invented;
- current Chrome, Firefox and Safari all support encoded transforms in 
some form (createEncodedStreams or RTCRtpScriptTransform);
- VP9 and AV1 simulcast/SVC do not require rewriting the payload.

What I have in mind is an opt-in, client-side-only feature that leaves 
the server untouched:

1. a per-group setting, or simply a key present in the URL fragment 
(never sent to the server), enables encryption in the browser;
2. frames are encrypted with SFrame (AES-256-GCM), keys derived from a 
shared group secret with HKDF; no new dependencies, only WebCrypto;
3. encrypted groups are restricted to VP9 or AV1, with whatever minimal 
unencrypted prefix Galène still needs for keyframe detection, documented 
explicitly;
4. the UI states clearly what this does and does not protect.


Before writing any code I would like to ask:

- Do you think the time is now right for this, or are there obstacles 
I'm missing?
- 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?
- Which unencrypted bytes, if any, does the current server actually need 
from VP9 and AV1 frames?

I'm happy to do the work and the cross-browser testing, and to start 
with a design note on the list.

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

Tell me you decision

Tkanks.

Best regards,


Alberto
mochela.it

[Galene] Re: End-to-end encryption, revisited (SFrame, client-side only)

[Juliusz Chroboczek]

> 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