Bug #81356 InnoDB Tablespace Encryption Not Supported for UNDO/REDO/BINLOGs
Submitted: 9 May 2016 18:38 Modified: 27 Mar 2020 19:04
Reporter: Matthew Boehm Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: Security: Encryption Severity:S3 (Non-critical)
Version:5.7.12 OS:Any
Assigned to: CPU Architecture:Any
Tags: encrypted, encryption

[9 May 2016 18:38] Matthew Boehm
When using encrypted InnoDB tablespaces, undo logs, redo logs and binary logs do not contain encrypted data.

How to repeat:
Create a table using ENCRYPTION='Y'
Insert a row
$ strings binlog.00001
View plaintext data

$ strings ib_logfile0 | grep <row data>
View plaintext data

Suggested fix:
Implement encrypted data in undo/redo/binlogs
[10 May 2016 10:10] MySQL Verification Team
Hello Matthew,

Thank you for the report.
Imho - this is a limitation and documented behavior "InnoDB tablespace encryption only supports InnoDB tables that are stored in a file-per-table tablespaces. Encryption is not supported for tables stored in other InnoDB tablespace types including general tablespaces, the system tablespace, undo log tablespaces, and the temporary tablespace" in https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html

Verifying as reasonable feature request after discussing internally with Dev's.

[16 May 2016 3:59] Matthew Boehm
Hi Umesh,
Encryption for the UNDO/REDO is supported in Oracle. (http://www.oracle.com/technetwork/database/security/tde-faq-093689.html) I would expect MySQL to attempt similar progress in this area.

Support for encryption in the BINLOG would probably require a new binlog event type where the ROW-event is encrypted using the tablespace key provided by the master. If the same keyring isn't present on the slave, decryption within the slave thread cannot happen.
[27 Mar 2020 19:04] Matthew Boehm
I guess this can be closed now that 8.0 supports UNDO/REDO/Binlog encryption?