En realidad, no hay nada malo con su primera consulta, sintácticamente es perfecto como lo demuestra este ejemplo resuelto.
mysql> SET @@SESSION.block_encryption_mode = 'aes-256-cbc';
mysql> create table MyTable(
-> Encrypted_ID varbinary(256),
-> InitializationVector_iv varbinary(16)
-> );
Query OK, 0 rows affected (0.93 sec)
mysql> SET @iv = RANDOM_BYTES(16);
Query OK, 0 rows affected (0.00 sec)
mysql> INSERT INTO MyTable SET Encrypted_ID = AES_ENCRYPT('hello','key', @iv), InitializationVector_iv = @iv;
Query OK, 1 row affected (0.17 sec)
mysql> SELECT CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) from MyTable;
+------------------------------------------------------------------------+
| CAST(AES_DECRYPT(Encrypted_ID,'key', InitializationVector_iv) AS CHAR) |
+------------------------------------------------------------------------+
| hello |
+------------------------------------------------------------------------+
1 row in set (0.00 sec)
En cuanto a por qué no funciona, logré que la consulta devolviera NULL en 2 escenarios. Uno, obtiene NULL devuelto si usa un iv diferente para el cifrado y descifrado, por lo que es posible que desee ver cómo está almacenando como iv. Dos, obtiene NULL donde tiene la variable block_encryption_mode configurada de manera diferente al almacenar e intentar recuperar el valor, verifique que no esté volviendo accidentalmente al valor predeterminado 'aes-128-ebc entre sesiones. Puede haber otros...
La segunda consulta fallará porque necesita proporcionar el iv a las funciones de cifrado y descifrado, solo lo usa para cifrar. Además, dado que está tomando los valores de MyTable, Encrypted_ID ya estará encriptado y el efecto de esta consulta sería encriptarlo nuevamente, antes de revertirlo para regresar al valor almacenado (encriptado).
Finalmente, AES solo usará 16 bytes del iv así que también podrías hacer ese VARBINARY(16).
