cryptex is defined in IETF RFC 9335.
It is a standard specification intended to encrypt RTP header extensions and contributing sources.
An RTP can be seen as split into 3 main parts: the RTP header (with contributing sources and extensions), payload header and the payload itself.
The RTP header is meant to be quite lean (and designed so that Cisco routers can read it and do something smart), but includes the ability to add header extensions, which is quite popular and widely used by WebRTC implementations.
Contributing sources are an indication in the RTP packet of which sources contributed to this packet. This can be a list of sources that had their media mixed together by an MCU for example. Google uses this heavily in Google Meet.
In WebRTC, we encrypt all media at all times using SRTP. The encryption used by SRTP does not encrypt the RTP header on purpose – without having that in the clear, it will be impossible to reorder, handle packet loss and playback the media being sent.
The fact that the RTP header isn’t encrypted, means that the header extensions and contributed sources are sent in the clear, which can breach privacy, e.g. in the case of the audio level (no known attacks exist) or corruption detection and give too much information to would-be assailants. cryptex comes to solve that by encrypting these pieces of RTP packets as well.
cryptex is new to the scene of WebRTC and is expected to be made part of the implementation soon.
