Ad

Strange Characters Like: � Are Appearing When Using Mcrypt_decrypt On CentOS

I want to encrypt access tokens, and decrypt it at some point.

The content of my table looks like this: enter image description here

I used the built-in function of Mysql AES_ENCRYPT() in the following way:

UPDATE users SET access_token = AES_ENCRYPT('adummyaccesstoken', '1234567890123456') WHERE id = 1;

On WAMP my code looks like this:

try{
    $user = "root";
    $pass = "";
    $dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass);
}
catch (PDOException $e) {
    print "Error!: " . $e->getMessage() . "<br/>";
    die();
}

$statement = $dbh->prepare("SELECT * FROM `users` WHERE id = 1");
$statement->execute();
$row = $statement->fetch(PDO::FETCH_ASSOC); 

$row['decrypted_token'] = trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, '1234567890123456', $row['access_token'], MCRYPT_MODE_ECB));
var_dump($row);

On WAMP the result is this:

array (size=5)
  'id' => string '1' (length=1)
  'firstname' => string 'Pim' (length=3)
  'lastname' => string 'van der Wal' (length=11)
  'access_token' => string 'Äk„
vl¢Þ?ÍØ%tkѲúiLï4]«~Ô‡íW' (length=32)
  'decrypted_token' => string 'adummyaccesstoken' (length=32)

I applied the same approach to my webapplication which is running on CentOS.

$decryptToken = trim(mcrypt_decrypt(MCRYPT_RIJNDAEL_128, '1234567890123456', $this->accessToken, MCRYPT_MODE_ECB));
echo $decryptToken;

Result:

��m�N��kA��%+��q���/��Ĝx��ϐۊ�e  �/+�d�@vU��

Question I can't understand why it returns the code in such a weird way. I suspect that this has to do with a character set mismatch when reading the decrypted token.

Any help is appreciated.

Ad

Answer

The encrypted data is binary - it doesn't have character representation or encoding - it's not text

The result show here:

'access_token' => string 'Äk„
vl¢Þ?ÍØ%tkѲúiLï4]«~Ô‡íW' (length=32) 

is probably the iso-8895-1 interpretation of the binary. Note how something in the binary data has matched carriage return - that'll be 0A. ² = B2, and so on. You'll see this if you use the Windows console or open the file in notepad.

The result you're seeing on CentOS is probably because your terminal or editor is configured for UTF-8. Any bytes sent to the terminal are interpreted as UTF-8. In UTF-8, most bytes above 7F will need matching surrogate bytes, which a near random string won't have produced, hence the replaced characters.

As you're storing binary data in the database, ensure that your field for the token is a blob and not varchar. Using varchar will lead to text character-translation problems.

In short, you don't need to worry as the underlying data is the same.

Ad
source: stackoverflow.com
Ad