This the second stage in our E2EE journey.
Instead of using a single pre-shared passphrase for deriving the key used for
E2EE, we now establish a secure E2EE communication channel amongst peers.
This channel is implemented using libolm, using XMPP groupchat or JVB channels
as the transport.
Once the secure E2EE channel has been established each participant will generate
a random 32 byte key and exchange it over this channel.
Keys are rotated (well, just re-created at the moment) when a participant joins
or leaves.
moves the cryptography bit to a datastructure which allows per-sender keys.
Does not yet use per-sender keys.
Also fixes lots of lint errors in the worker.
e2ee: don't pass plain frames to decoder if we are encrypting (#1116)
If we are encrypting and the key index from a (potentially unencrypted)
frame exceeds our key ring size (1 currently) drop the frame.
This is a heuristic. We currently don't have the signaling for whether a
remote end does encrypt its frames or not.
Reverts #1098, that strategy does not work. When switching from garbage to non-garbage the decoder
would decode subsequent packets based on the wrong keyframe.
e2ee: decode static black frame for decryption errors (#1098)
similar to #1095 use a black keyframe instead of displaying a potentially
unencrypted stream. This was again captured with a modified version of
the webrtc sample, additional logging and a resolution of 320x180
e2ee: generate silence in case of audio decryption errors
This handles decryption errors for audio differently than the
current version. Instead of forwarding horrible noise to the decoder,
replace the bytes with magic opus bytes for silence:
0xd8fffe
Those bytes were captured on a modified version of
https://webrtc.github.io/samples/src/content/peerconnection/endtoend-encryption/
with more dumping and after disabling the track.
Saúl Ibarra Corretgé
Philipp Hancke
Philipp Hancke
Alfredo Irarrazaval