The file_key_management plugin enables file_key_management_encryption_algorithm=AES_CTR at compile time if the TLS library supports AES-CTR:

https://github.com/MariaDB/server/blob/592fe954ef82be1bc08b29a8e54f7729eb1e1343/plugin/file_key_management/file_key_management_plugin.cc#L29

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).

https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#choosing-an-encryption-algorithm

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:

https://github.com/MariaDB/server/blob/592fe954ef82be1bc08b29a8e54f7729eb1e1343/plugin/file_key_management/file_key_management_plugin.cc#L109

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?