E2EE: allow setting key_ring_size and key_derivation_algorithm, update webrtc to m144

[onestacked]

This PR uses this webrtc-sdk PR to configure the KDF, instead of just overwriting the derived key afterwards. This should also now properly support KeyRatcheting.

I've tested this with https://codeberg.org/esoteric_programmer/matrix-jukebox and it is compatible with Element Call.

Since this PR needs to use a new webrtc build it also updates webtc to m144. See this PR

Fixes: #796

[onestacked]

Now based on webrtc-sdk/webrtc#224

[onestacked]

webrtc-sdk/webrtc#224 is now merged, this will only need a new webrtc-sdk build and update to that. (once thats done I'll look into why node fails.

[alexander-potemkin]

Please, keep going, @onestacked !! :)

[onestacked]

This is mosly waiting for review and the WebRTC build to be done.
From my side there isn'tuch to do anymore, just fixing the CI (which needs something for node) and maybe adding some tests. Most of the CI failures are because this uses a local WebRTC build which of course doesn't exust in CI.

[alexander-potemkin]

@theomonnom , @typester , I hope you would forgive me for pinging you directly. I'm just a person who wants to help a very needed work from @onestacked to make to your product.

[maxinflection]

We've been running a production deployment with an equivalent patch set for about three weeks now — a Matrix bot that joins Element Call rooms via LiveKit, decrypts E2EE audio, and transcribes it. Our patches target the same layers (webrtc C++ → webrtc-sys → livekit crates → livekit-ffi) and the approach is functionally identical: branch on a KeyDerivationAlgorithm enum in DeriveKeys(), call BoringSSL's HKDF() with EVP_sha256(), and thread the option through the Rust/FFI stack.
Can confirm:
• HKDF-SHA256 with salt "LKFrameEncryptionKey" and 128 zero-byte info produces correct AES-128-GCM keys matching Element Call's JS SDK
• Key ratcheting still works correctly when left on PBKDF2 (default path unchanged)
• Tested against Element Call clients on Element Web and Element X

Happy to help test once the new webrtc-sdk release unblocks this. Looking forward to dropping our custom .so build.

[onestacked]

Webrtc-sdk has just been rebased to a new upstream release: webrtc-sdk/webrtc#217 so livekit will probably update fairly soon.

[fkwp]

We've been running a production deployment with an equivalent patch set for about three weeks now — a Matrix bot that joins Element Call rooms via LiveKit, decrypts E2EE audio, and transcribes it. Our patches target the same layers (webrtc C++ → webrtc-sys → livekit crates → livekit-ffi) and the approach is functionally identical: branch on a KeyDerivationAlgorithm enum in DeriveKeys(), call BoringSSL's HKDF() with EVP_sha256(), and thread the option through the Rust/FFI stack. Can confirm: • HKDF-SHA256 with salt "LKFrameEncryptionKey" and 128 zero-byte info produces correct AES-128-GCM keys matching Element Call's JS SDK • Key ratcheting still works correctly when left on PBKDF2 (default path unchanged) • Tested against Element Call clients on Element Web and Element X

Happy to help test once the new webrtc-sdk release unblocks this. Looking forward to dropping our custom .so build.

that's nice @maxinflection that MatrixRTC is getting traction around the matrix rust-sdk. I think the community would be really interested in your project. So yes please share your stuff :-)

[onestacked]

I'm not sure why the FFI Proto fails on checkout?

I don't think any change should effect this.

[onestacked]

Also let me know if you want my PR split, as it now does three things (key_ring_size, key_derivation_algorithm and webrtc update)

[cloudwebrtc]

Hey, this is a version that will be released soon webrtc-24f6822-2. You can update to it now. And the m144 upgrade will begin next week.

[cloudwebrtc]

Please revert to m137_release here first. We will modify this section again after updating to m144.