MySql WorkBenchAES256復号化

最初のクエリには実際には何も問題はありません。この実際の例が示すように、構文的には問題ありません。

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)

それが機能しない理由については、2つのシナリオでクエリがNULLを返すようにすることができました。 1つは、暗号化と復号化に異なるivを使用すると、NULLが返されるため、ivとしてどのように保存しているかを確認することをお勧めします。 2つ目は、値を保存および取得しようとしたときにblock_encryption_mode変数が異なる方法で設定されている場合にNULLを取得し、セッション間で誤ってデフォルトの'aes-128-ebcに戻らないことを確認します。他にもあるかもしれません...

2番目のクエリは、暗号化機能と復号化機能の両方にivを提供する必要があるため失敗します。これは、暗号化にのみ使用します。また、MyTableから値を取得しているため、Encrypted_IDはすでに暗号化されており、このクエリの効果は、保存された（暗号化された）値に戻す前に、再度暗号化することです。

最後に、AESは16のみを使用します。バイト ivのので、そのVARBINARY（16）を作成した方がよいでしょう。