[MDEV-8587] Aria log encryption Created: 2015-08-09  Updated: 2023-12-22

Status: Open
Project: MariaDB Server
Component/s: Documentation, Encryption, Storage Engine - Aria
Fix Version/s: None

Type: Task Priority: Minor
Reporter: Elena Stepanova Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File enc_add_ch_rm_rec.patch    
Issue Links:
Relates
relates to MDEV-20099 Implement key rotation for Aria Open
relates to MDEV-17324 Make information_schema table that sh... Open
relates to MDEV-18049 Support ENCRYPTED and ENCRYPTION_KEY_... Open
relates to MDEV-18971 Add background encryption threads for... Open

 Description   

For Aria, only table files get encrypted, while Aria log apparently does not. I assume it's on purpose, but then it should probably mentioned in the documentation, I could not find anything about it.

A short specification if we would make Aria log encrypted:

  • First log page of each log file should not be encrypted (has no user data, so it's not important). However we can add a marker on the first page that the file is encrypted, including some 'random' encryption seed used for the rest of the file.
  • We encryption key could be depending on something that changes, like the file number (part of the file name) and the above encryption seed. Note that we need to be able to access all keys ever used for the logs also with aria_read_log and aria_dump_log !
  • Each log file is either fully encrypted (except for first page) or not at all. One should be able to mix encrypted at not encrypted files.
  • The Aria log is designed so that one can write additional data on a log page without affecting the previous content on the page. Encrypted files must do the same! This is critical as the engine assumes that if a page part has been written and synced it, it will always be able to read that part again, even if future writes on the same page would fail or be half written! One implication of this is that each write to the log page should be independently encrypted!
  • Encrypted segments can have additional data or be longer than non encrypted segments. This may be needed if the encrypted data is longer than the not encrypted data (for example if there needs to be a checksum for each encrypted segment).

 Comments   
Comment by Kolbe Kegel (Inactive) [ 2016-03-07 ]

I added this limitation to https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/#limitations.

Comment by Ralf Gebhardt [ 2018-06-29 ]

serg Do we need to get the logs encrypted when we want to use Aria as the storage engine for system tables?

Comment by Sergei Golubchik [ 2018-07-01 ]

If you want to use Aria for system tables and want to have these system tables encrypted, then yes.

If you want to use Aria for system tables and want to have these system tables encrypted but without log encryption, it'll still be better than using MyISAM, but only marginally.

Comment by Geoff Montee (Inactive) [ 2018-12-20 ]

I added this:

https://mariadb.com/kb/en/library/encrypting-data-for-aria/#encryption-and-the-aria-log

Comment by Elena Stepanova [ 2021-01-19 ]

Reminder: wanted or not, we now do have Aria for system tables, but still no log encryption.

Also, it is probably worth mentioning somewhere in the documentation that Aria encryption must be enabled before the system tables are created, which can be a bit cumbersome. But I suppose it is not extremely important as long as the log is not encrypted anyway.

Comment by Yuri Radchenko [ 2022-07-19 ]

Please, check this patch.
enc_add_ch_rm_rec.patch

my.cnf

general_log
log-bin

plugin_load_add = file_key_management
file_key_management_filename = /etc/mysql/encryption/keyfile.enc
file_key_management_filekey = FILE:/etc/mysql/encryption/keyfile.key
file_key_management_encryption_algorithm = AES_CTR

#encrypt_binlog=ON
#aria_encrypt_tables = ON
aria_encrypt_translog = ON

Comment by Yuri Radchenko [ 2022-08-16 ]

I implemented aria log encryption for adding/changing/deleting records.

Comment by Oleksandr Byelkin [ 2023-02-22 ]

After discussion with Serg how it supposed to work, I do not see in the patch:

The key should be also based on something which changes (file number (may be page number, but I doubts)) and some randomly choosen data (just written in the unencripted part of the file (the header page do not need any encription, it has predicted content with no user data so it only will help decript data)) which allow better protection of the data which frequently are the same.

Comment by Oleksandr Byelkin [ 2023-03-01 ]

jorje_rd the above is the main problem with the patch wich prevent it to be accepted

Comment by Yuri Radchenko [ 2023-03-01 ]

Ok. But I didn't do anything new. I took the table encryption code and ported it to log encryption.

Comment by Andrew Hutchings [ 2023-03-01 ]

jorje_rd can you please declare that you are providing this commit under the 3-clause BSD license?

Comment by Yuri Radchenko [ 2023-03-01 ]

Yes. I did it just for fun. You can put any license, including the 3-clause BSD license.

Comment by Andrew Hutchings [ 2023-03-14 ]

jorje_rd as an FYI, Monty has updated the description of this ticket with everything that is needed to make this work safely.

Generated at Thu Feb 08 07:28:16 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.