[hiroshihorie]

Summary

In shared-key E2EE mode, BaseKeyProvider.setSharedKey(key, keyIndex: n) passed n to the native key ring but never recorded it. getLatestIndex() only read the per-participant map, so in shared-key mode it always returned 0. Two things read that value:

• new sender frame cryptors (E2EEManager._addRtpSender)
• encrypted data packets (encryptData)

So an app that keeps its shared key at a non-zero index got tracks whose sender cryptor pointed at slot 0. Epoch-based rotation with epoch % keyRingSize is one example. What happened next depended on what slot 0 held:

• Empty: the sender dropped every frame with missingKey.
• An older key: receivers could not decrypt.

Either way the publication looked healthy and the app saw no error. The only workaround was calling e2eeManager.setKeyIndex() after every publish, and that races the cryptor setup.

Change

• setSharedKey now records the index.
• In shared-key mode, getLatestIndex() returns that index for every participant.
• The recorded index is the key ring slot the key lands in: the index modulo the ring size, with the ring clamped to 1 to 256 the way the native key ring does it. A key set at index 16 in a ring of 16 is in slot 0, so a new sender now starts at 0 there, not at 16, which is outside the ring. This applies to per-participant mode too.
• A negative index no longer moves the recorded index. The key ring writes such a key into the current slot without moving it.
• On web, the worker now applies the key index it receives for dataCryptorEncrypt. It used to ignore it and always encrypt data packets with the key in slot 0.

This matches the JS SDK, where the sender reads the key handler's current index. It also matches livekit/client-sdk-swift#1157, which starts new Swift sender cryptors at the key provider's current index.

Existing cryptors are not moved when setSharedKey changes the index. Apps still move live tracks with E2EEManager.setKeyIndex() as before. So a rotation that installs the new key first and switches later keeps working.

The branch also merges main, which brings the flutter_webrtc 1.6.3 pin the e2e harness needs.

Testing

• test/e2ee/key_provider_test.dart covers the shared index, the ring wrap (16 and 19 in a ring of 16, 260 in a ring of 300 clamped to 256), the negative index and the per-participant wrap. Each case fails without the change it covers.
• flutter test (487 passed, 1 skipped), flutter analyze, dart format and import_sorter all pass. The web worker compiles with dart compile js.
• A new e2e-flutter scenario, E2EESharedKeyIndexTest (branch hiroshi/e2ee-shared-key-index-scenario in livekit/e2e-flutter), installs a shared key at index 3 with nothing in slot 0, publishes the camera, and checks the sender's key index and that the receiver decrypts. It repeats with index 21 in a ring of 16. On macOS against a local server:
  • this branch passes, as does the whole e2ee tag (3 of 3)
  • without the ring wrap commit, the second phase fails with the sender at index 21
  • on main, the first phase fails with the sender at index 0, and the receiver never decrypts because the sender drops every frame

Not covered yet:

• The web data packet fix has not been run in a browser.
• An E2EEManager-level unit test that a new sender cryptor receives the index. The e2e scenario covers it end to end.