Der er faktisk ikke noget galt med din første forespørgsel, syntaktisk er den spot on, som dette udførte eksempel viser.
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)
Med hensyn til hvorfor det ikke virker, lykkedes det mig at få forespørgslen til at returnere NULL i 2 scenarier. For det første får du NULL returneret, hvis du bruger en anden iv til kryptering og dekryptering, så du vil måske se på, hvordan du gemmer som iv. For det andet får du NULL, hvor du har indstillet variabelen block_encryption_mode anderledes, når du gemmer og forsøger at hente værdien, tjek at du ikke ved et uheld vender tilbage til standard 'aes-128-ebc mellem sessioner. Der kan være andre...
Den anden forespørgsel vil mislykkes, fordi du skal levere iv'en til både krypterings- og dekrypteringsfunktionerne, du bruger den kun til at kryptere. Da du også tager værdierne fra MyTable, vil Encrypted_ID allerede være krypteret, og effekten af denne forespørgsel ville være at kryptere den igen, før den vendes tilbage for at få dig tilbage til den lagrede (krypterede) værdi.
Endelig vil AES kun bruge 16 bytes af iv, så du kan lige så godt lave den VARBINARY(16).