MySQL Bugs: #81356: InnoDB Tablespace Encryption Not Supported for UNDO/REDO/BINLOGs

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:	None
Category:	MySQL Server: Security: Encryption	Severity:	S3 (Non-critical)
Version:	5.7.12	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	encrypted, encryption

Description:
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

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.

Thanks,
Umesh

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.

I guess this can be closed now that 8.0 supports UNDO/REDO/Binlog encryption?