Er is eigenlijk niets mis met je eerste zoekopdracht, syntactisch gezien klopt het, zoals dit uitgewerkte voorbeeld laat zien.
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)
Wat betreft de reden waarom het niet werkt, is het me gelukt om de query NULL te laten retourneren in 2 scenario's. Ten eerste krijg je NULL terug als je een andere iv gebruikt voor codering en decodering, dus misschien wil je kijken hoe je opslaat als de iv. Twee, je krijgt NULL waar je de block_encryption_mode variabele anders hebt ingesteld bij het opslaan en proberen op te halen van de waarde, controleer of je niet per ongeluk teruggaat naar de standaard 'aes-128-ebc tussen sessies. Er kunnen andere zijn...
De tweede query zal mislukken omdat je de iv moet leveren aan zowel de coderings- als decoderingsfuncties, je gebruikt het alleen om te coderen. Omdat u de waarden uit de MyTable haalt, is Encrypted_ID al gecodeerd en het effect van deze vraag zou zijn om deze opnieuw te coderen, voordat u dat terugdraait om u terug te brengen naar de opgeslagen (gecodeerde) waarde.
Ten slotte gaat AES alleen 16 gebruiken bytes van de iv, dus je kunt net zo goed die VARBINARY (16) maken.