Thực ra không có gì sai với truy vấn đầu tiên của bạn, về mặt cú pháp, nó được phát hiện đúng như ví dụ hoạt động này chứng minh.
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)
Đối với lý do tại sao nó không hoạt động, tôi đã quản lý để nhận được truy vấn để trả về NULL trong 2 tình huống. Một, bạn nhận được NULL trả về nếu bạn sử dụng iv khác để mã hóa và giải mã, vì vậy bạn có thể muốn xem cách bạn đang lưu trữ như iv. Thứ hai, bạn nhận được NULL nơi bạn có biến block_encryption_mode được đặt khác khi lưu trữ và cố gắng truy xuất giá trị, hãy kiểm tra để đảm bảo rằng bạn không vô tình hoàn nguyên về mặc định 'aes-128-ebc giữa các phiên. Có thể có những người khác ...
Truy vấn thứ hai sẽ không thành công vì bạn cần cung cấp iv cho cả hai chức năng mã hóa và giải mã của anh ta, bạn chỉ sử dụng nó để mã hóa. Ngoài ra, vì bạn đang lấy các giá trị từ MyTable, Encrypted_ID sẽ được mã hóa và tác dụng của truy vấn này là mã hóa lại nó, trước khi đảo ngược điều đó để đưa bạn trở lại giá trị đã lưu trữ (đã mã hóa).
Cuối cùng, AES sẽ chỉ sử dụng 16 byte của iv để bạn cũng có thể tạo VARBINARY (16).
