On 1/16/08, Ken Kixmoeller -- reply to [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
>
> On Jan 16, 2008, at 1:28 AM, Andrés Robinet wrote:
>
> His other post explains that php didn't seem to like spaces. No
> spaces in the test strings -- I'll check for those when/if I can get
> the core en/decryption working.
See below - I had an issue with a .NET encrypted string in a cookie
and decrypting it in PHP. It was required for that. I think it might
be due to how .NET does it's base64 encoding; but I've kept it in my
code just in case even for pure PHP.
Here are my encrypt/decrypt functions. This is -not- the previous
.NET/PHP exchange I mentioned. That uses a weaker bit AES due to
.NET's defaults
function data_encrypt($data) {
if(!$data) { return false; }
return base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], $data, 'cbc', md5($GLOBALS['config']['
salt'].$GLOBALS['config']['salt'])));
}
function data_decrypt($data) {
if(!$data) { return false; }
return rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256,
$GLOBALS['config']['salt'], base64_decode(str_replace(' ', '+',
$data)), '
cbc', md5($GLOBALS['config']['salt'].$GLOBALS['config']['salt'])));
}
where $config['salt'] in a config file is your random key. make it
something worthwhile like "haX0r$sUCK!" that won't ever be easily
guessed.
I have code like this running on a couple sites - works like a charm,
that includes using it to encrypt cookie data and decrypt it on the
way back. I am not entirely sure if the str_replace for the spaces is
-required- for a PHP to PHP encryption/decryption, but it doesn't seem
to hurt, and I don't believe this should fail for any reason in your
tests...
The one caveat is I think it is suggested to use the mcrypt_generic()
functions now, which I believe meant writing a bunch more lines of
code and I liked my single line solution (and I might have had an
issue for some reason trying to make it work... I'll probably have to
redo this someday either way)
