PEAR is archived and read-only

This mirror preserves historical PEAR package releases and metadata so existing references remain available.

Home » Encryption » Crypt_Blowfish » Bug #7945

nul-padding needs doc / option

Details

Submitted2006-06-20 15:58 UTC
Frompear dot 20 dot korkman at spamgourmet dot org
Assignedjausions
StatusClosed
PackageCrypt_Blowfish
PHP Version5.1.1
OSSuSE 9.0 in VMWare
Roadmaps(Not assigned)

Comments

[2006-06-20 15:58 UTC] pear dot 20 dot korkman at spamgourmet dot org

Description:
------------
The returned String from decrypt() is nul-padded to be a multiple of 8 bytes minus one. That is chr(0), EOF! Dangerous to work with as non-binary-safe functions cut off the string on that. Please at least mention it in the description of ->decrypt().

Further this makes crypt/decrypt non-binary-safe as I understand that there is no way to tell how many nul-bytes where at the end of the crypt input. A solution would be to encode the length of the encrypted string into the output, then use that information upon decrypt to substr() the string to the correct length. This should probably be the default behaviour of the PEAR-Class, as the other Crypt_* Classes are binary-safe, and except of this one can be exchanged pretty easily.

On the other hand, this would break backwards compatibility and may cause problems when exchanging encrypted data with other applications.

Test script:
---------------
$test_string = 'what the!'.chr(0);

$fish = new Crypt_Blowfish('testkey');
$new_test_string = $fish->encrypt($test_string);
$new_test_string = $fish->decrypt($new_test_string);

for ($i = 0; $i < strlen($new_test_string); $i++)
{
echo "-" . ord(substr($new_test_string, $i, 1));
}

Expected result:
----------------
-119-104-97-116-32-116-104-101-33-0

// One nul-byte at the end

Actual result:
--------------
-119-104-97-116-32-116-104-101-33-0-0-0-0-0-0-0

// Many nul-bytes at the end