Encrypting Binary Log Files and Relay Log Files The binary log encryption key that is currently in use on the server is called the binary log master key. The sequence number for the current binary log master key is stored in the keyring. The binary log master key is used to encrypt each new log file’s file password, which is a randomly generated 32-byte file password specific to the log file that is used to encrypt the file data. The file password is encrypted using AES-CBC (AES Cipher Block Chaining mode) with the 256-bit binary log encryption key and a random initialization vector (IV), and is stored in the log file’s file header. The file data is encrypted using AES-CTR (AES Counter mode) with a 256-bit key generated from the file password and a nonce also generated from the file password. It is technically possible to decrypt an encrypted file offline, if the binary log encryption key used to encrypt the file password is known, by using tools available in the OpenSSL cryptography toolkit. If you use file copying to clone a MySQL server instance that has encryption active so its binary log files and relay log files are encrypted, ensure that the keyring is also copied, so that the clone server can read the binary log encryption keys from the source server. When encryption is activated on the clone server (either at startup or subsequently), the clone server recognizes that the binary log encryption keys used with the copied files include the generated UUID of the source server. It automatically generates a new binary log encryption key using its own generated UUID, and uses this to encrypt the file passwords for subsequent binary log files and relay log files. The copied files continue to be read using the source server’s keys. When binary log encryption is enabled, you can rotate the binary log master key at any time while the server is running by issuing  ALTER INSTANCE ROTATE BINLOG MASTER KEY . When the binary log master key is rotated manually using this statement, the passwords for the new and subsequent files are encrypted using the new binary log master key, and also the file passwords for existing encrypted binary log files and relay log files are re-encrypted using the new binary log master key, so the encryption is renewed completely. You can rotate the binary log master key on a regular basis to comply with your organization’s security policy, and also if you suspect that the current or any of the previous binary log master keys might have been compromised. When you rotate the binary log master key manually, MySQL Server takes the following actions in sequence: The  BINLOG_ENCRYPTION_ADMIN  privilege is required to issue  ALTER INSTANCE ROTATE BINLOG MASTER KEY , and the statement cannot be used if the  binlog_encryption  system variable is set to OFF . As the final step of the binary log master key rotation process, all binary log encryption keys that no longer apply to any retained binary log files or relay log files are cleaned up from the keyring. If a retained binary log file or relay log file cannot be initialized for re-encryption, the relevant binary log encryption keys are not deleted in case the files can be recovered in the future. For example, this might be the case if a file listed in 1. A new binary log encryption key is generated with the next available sequence number, stored on the keyring, and used as the new binary log master key. 2. The binary log and relay log files are rotated on all channels. 3. The new binary log master key is used to encrypt the file passwords for the new binary log and relay log files, and subsequent files until the key is changed again. 4. The file passwords for existing encrypted binary log files and relay log files on the server are re- encrypted in turn using the new binary log master key, starting with the most recent files. Any unencrypted files are skipped. 5. Binary log encryption keys that are no longer in use for any files after the re-encryption process are removed from the keyring. 3620 17.3.2.3 Binary Log Master Key Rotation