An alternative to Insertable Streams, currently implemented in Safarii / WebKit.

https://w3c.github.io/webrtc-encoded-transform/

Fixes: https://github.com/jitsi/jitsi-meet/issues/9585

remove legacy APIs which are not even supported anymore

Drop end to end signature. The impersonation attack vector is deemed out of
scope since insiders are already part of the meeting.

Signs and verifies frames. For now this is done on every frame.
This is not the long-term goal and there needs to be a better strategy.

to allow writing tests

in particular this allows sharing the ratcheting between the E2EEncryption
module and the Worker.

similar to what is explained here:
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we do it on authentication tag failures since it is not possible
to tell whether decrypt.

this needs to be called with an Uint8Array, not an ArrayBuffer

refactor the signature checking to make it clear when we need to ratchet.
This is similar to
  https://tools.ietf.org/html/draft-omara-sframe-00#section-4.3.5.1
but we verify the hash before attempting to decrypt.

following
  https://tools.ietf.org/html/draft-omara-sframe-00
but putting the frame metadata into a trailer instead of a header.
We call this JFrame.

Also the key we get from OLM is high entropy so we do not need
to use PBKDF2 but can use HKDF instead. See
  https://wiki.developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/deriveKey#HKDF

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.

Avoid having to use a code blob.

which landed in
  https://bugs.chromium.org/p/chromium/issues/detail?id=1069295#c4

derived from the participant id in addition to the salt, separated by a null
byte to avoid ambiguity attacks along the lines of
  (someRoom, someParticipant)
  (someRoo, mSomeParticipant)

as suggested during the community call recently

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.

Mobile breaks otherwise, since creating those types of URLs are supported.

Moveѕ e2ee operations to a worker that is included as text/blob for now
to simplify deployment.

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.

no longer required as of Chrome 84.0.4108.0 and has been merged into M83 as well.

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

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.

Co-authored-by: Saúl Ibarra Corretgé <saghul@jitsi.org>