I've found similar questions, but no clear answer for this question. I have this table:
CREATE DATABASE testDB DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
CREATE TABLE testTable
(
firstName binary(32) not null,
lastName binary(32) not null
/* Other non-binary fields omitted */
)
engine=INNODB DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
This statement executes just fine:
INSERT INTO testTable (firstName) VALUES (AES_ENCRYPT('Testname', 'test'));
But, this returns NULL:
SELECT AES_DECRYPT(firstName, 'test') FROM testTable;
Why does this return NULL?
Fwiw, this returns "testValue" as expected:
SELECT AES_DECRYPT(AES_ENCRYPT('testValue','thekey'), 'thekey');
The answer is that the columns are binary
when they should be varbinary
. This article explains it:
Because if AES_DECRYPT() detects invalid data or incorrect padding, it will return NULL.
With binary
column types being fixed length, the length of the input value must be known to ensure correct padding. For unknown length values, use varbinary
to avoid issues with incorrect padding resulting from differing value lengths.
When you insert binary data into a VARCHAR field there are some binary characters that a VARCHAR can't handle and they will mess up in the inserted value. And then the inserted value will not be the same when you retrieve it. 1.select hex(aes_encrypt(file,'key')); 2.select aes_decrypt(unhex(file),'key');
Check if type of your field is blob instead binary(32)
Did you try different values other than 'Testname'? Do other values work?
I ask because I had a situation while testing 2 test credit card numbers where one decrypted fine and the other returned null.
The answer was to hex and unhex as suggested by "abhinai raj"
来源:https://stackoverflow.com/questions/16224515/why-is-aes-decrypt-returning-null