How the RTC plugin encryption works

TinyMCE’s Real-time Collaboration (RTC) plugin will be retired and deactivated on December 31, 2023, and is no longer available for purchase.

This section contains the technical details of the encryption used to securely transmit document content. It is provided for information purposes only; an understanding of these details is not required to use the RTC plugin.

For information on how to set up an encryption endpoint for Real-time Collaboration, see: Real-time Collaboration (RTC) Encryption Setup

The Real-time Collaboration (RTC) plugin does not use the provided encryption key to encrypt content directly. The plugin derives a unique session key from the provided key using industry standard cryptography algorithms. This method of content encryption improves protection against brute force decryption.

The Real-time Collaboration (RTC) protocol encryption technique is as follows:

  • As described above, each document ID used for collaboration may have multiple sessions. To ensure each session has a unique key, 256 bits of random data are generated as the salt for each session along with a randomly generated AES-256 key. The salt is generated using the Crypto.getRandomValues() browser API and a 32 byte Uint8Array.

  • The salt data and the provided encryption key are combined using a PBKDF2 key derivation function. Derivation is performed by the SubtleCrypto.deriveKey() browser API, using the following parameters:

  • The derived key is used to wrap and unwrap the generated key, which is stored encrypted in the server session metadata. The unwrapped generated key is used with SubtleCrypto.encrypt() and SubtleCrypto.decrypt() as necessary, specifying the AES-GCM algorithm. For each encrypted message, 96 bits of random data are used as the initialization vector, also generated with Crypto.getRandomValues() but this time using a 12 byte Uint8Array. The initialization vector is transmitted alongside the encrypted message.

  • When a real-time collaboration session is established, the provided keyHint and protocol-generated salt are sent to the server through a HTTPS websocket connection, where they are stored as session metadata. When subsequent clients connect to the session, the server sends these values along with other session information so the client can derive the same unique key.

  • The provided key and derived key are never transmitted between clients. Each client will already have the provided key through the rtc_encryption_provider configuration, so only the salt needs to be transmitted for clients to derive the unique key. The salt alone cannot be used to decrypt the document content.

Our choice of encryption parameters results in an expensive derivation process, even on modern hardware, but the derivation is only performed once by each client when connecting to a session. Tiny is committed to the security and privacy of customer data, and Tiny has prioritized increased security over derivation performance. Once derivation is complete, encryption and decryption will be hardware accelerated.