in reply to Re^4: Perl encryption not matching PHP encryption
in thread Perl encryption not matching PHP encryption

There is typo in -keysize value.

And, what does get16() do? Rhetorical question that is to point out that you should provide a working code if you expect others to do experiments on your behalf.

In any case, note that 0x3d & 0x0a are converted by chr to "=" & newline characters. That newline character is coming most likely from &MIME::Base64::encode_base64 ...

encode_base64($str)
encode_base64($str, $eol)
Encode data by calling the encode_base64() function. The first argument is the string to encode. The second argument is the line-ending sequence to use. It is optional and defaults to "\n". The returned encoded string is broken into lines of no more than 76 characters each and it will end with $eol unless it is empty. Pass an empty string as second argument if you do not want the encoded string to be broken into lines.

Replies are listed 'Best First'.
Re^6: Perl encryption not matching PHP encryption
by johnnytc4 (Novice) on Apr 12, 2011 at 19:06 UTC
    A_Monk, Thanks for pointing that out. I was frantically trying diferrent combinations of the code and forgot to paste the running code. I've include get16 sub function and updated the perl code above. I used the "" for the $eol argument and that %0A has dropped off. I think the issue is the IV generation that the two languages generate. However I would like to believe that during the decrypt, the IV would be read and accounted for. But obviously my debugging skills are sub_par. Do you have any other ideas? WHAT each encrypt function generates when i use Ax16 for the IV ...

    PERL QUFBQUFBQUFBQUFBQUFBQcldXcuylXuYG%2BOav3Awis4%3D

    PHP QUFBQUFBQUFBQUFBQUFBQYZ0ZaS%2BWwtqd05V7CeJh%2BE%3D

[reply]
      NVM, i figured it out. the -literal_key => 1 did the trick. Thanks all for your help.
[reply]

In Section Seekers of Perl Wisdom