Details
-
Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Done
-
None
Description
The file_key_management plugin enables file_key_management_encryption_algorithm=AES_CTR at compile time if the TLS library supports AES-CTR:
However, when this option is set, the plugin might actually use either AES-CTR or AES-GCM, depending on the situation:
The AES_CTR mode uses AES in two slightly different modes in different contexts. When encrypting tablespace pages (such as pages in InnoDB, XtraDB, and Aria tables), it uses AES in the Counter (CTR) mode. When encrypting temporary files (where the cipher text is allowed to be larger than the plain text), it uses AES in the authenticated Galois/Counter Mode (GCM).
After MDEV-18531, wolfSSL will be the new bundled TLS library in MariaDB 10.4.6 and later. According to cmake/ssl.cmake, wolfSSL supports AES-CTR, but not AES-GCM:
https://github.com/MariaDB/server/blob/592fe954ef82be1bc08b29a8e54f7729eb1e1343/cmake/ssl.cmake#L59
Since wolfSSL doesn't support AES-GCM, it looks looks like the plugin will use AES-CTR in the cases where it would usually use AES-GCM, if the TLS library were OpenSSL:
Do we need to test whether file_key_management_encryption_algorithm=AES_CTR will work properly with wolfSSL?
Will this difference support migrations where the original server used OpenSSL, and the new server used wolfSSL (or vice-versa)? Or is AES-GCM only used in cases where the files won't be needed beyond server restarts?
Attachments
Issue Links
- relates to
-
MDEV-18531 Use WolfSSL instead of YaSSL as "bundled" SSL
- Closed