Description: ------------ The result of the encrypt function is not the same if i use Windows or Linux. I have XP SP2 and a Fedora Core 4. Test script: --------------- require_once "Crypt/Blowfish.php"; $plainText ="test"; $blowfish = new Crypt_Blowfish("mysecret"); $crypted = $blowfish->encrypt($plainText); // to have a human readable string $result = base64_encode($crypted); echo $result; echo "\n"; // to check that's base64_encode is ok $res = base64_encode($plainText); echo $res; Expected result: ---------------- Outputs should be same on both plateform Actual result: -------------- On Windows: A4iQeC9CuA4= dGVzdA== On Linux: j+bZjf/1YIA= dGVzdA==

There seems to be a problem with the fact that PHP only supports signed ints, and all of these operations are for unsigned int. It seems that on 64 bit systems, bitwise logic works, but on 32 bit systems, the ints get truncated as the manual says when being casted for the operator. I am guessing the Linux didn't have mcrypt installed, and the Windows did, or that the Windows was 64 bit.

It's interesting but i don't have 64bits machine. I made some tests using VirtualPC 2004. I tried Mandriva2006 and Ubuntu 5.10. The results are the same as my FC4 box, so still differents to my windows. I have access to a another machine running RH7.2 and compiled PHP5 and it worked!! Same results as windows. I made another test with another machine running FC1 and PHP4. It worked too. I asked a friend to test it on his MacOSX with PHP5 and it worked. Finally, I installed mcrypt on my FC4 box since Crypt_Blowfish uses it first. The tests have succedeed, so i decided to install mcrypt on the others linux and it was good. But it's not what I want. I need a encryption lib full PHP without using mcrypt. I can't figure out why it works on some linux and doesn't on others. Very strange.

Odd. It worked for us on a 64 bit Windows box, and a 2.4 Linux box. Not on a 2.6 Linux box, and not on my DragonFlyBSD 1.4 box (FreeBSD 4 fork). An easy test is this something like this: -2861207174 ^ 493813264 Which is the operation that was different in our test. good: 1209765738 bad: -1653670384 -2861207174 is out of range of PHP_MIN_INT or LONG_MIN, which is -2147483648. The funny thing is that I can reproduce the "good" results by doing -(2861207174 ^ 493813264). Probably because it is being stored internally as unsigned or something, when it can. I also noticed that on the good box, (float) -2861207174 ^ 493813264 still produces the good results. It seems to me that some systems are doing float bitwise operations like integer bitwise operations, and others aren't.

Zend is using this macro to convert floats to integers: #define DVAL_TO_LVAL(d, l) (l) = (d) > LONG_MAX ? (unsigned long) (d) : (long) (d) If it is longer than LONG_MAX, it stores it as an unsigned long, otherwise, it stores it as a signed long. Which seems to be why it works for me when I flip the sign before doing the operation, and then flip it back.

I have changed all "^" operators to use "binxor" function. Now it is working correctly with all systmes on which I tested it. function binxor($a, $b) { return bindec(decbin((float)$a ^ (float)$b)); } I have found this function in comments on PHP Manual: http://www.php.net/manual/en/language.operators.bitwise.php#56382 It was written by Eric Swanson.

I've just tried what you said and it works! Thanks Alexander! I ran 'pear run-tests' on windows and fedora and all tests passed. This is a diff of what i've made: 128c128,137 < --- > > /** > * > * http://www.php.net/manual/en/language.operators.bitwise.php#56382 > */ > function binxor($a, $b) > { > return bindec(decbin((float)$a ^ (float)$b)); > } > 151,153c160,162 < $temp = $Xl ^ $this->_P[$i]; < $Xl = ((($this->_S[0][($temp>>24) & 255] + < $this->_S[1][($temp>>16) & 255]) ^ --- > $temp =$this-> binxor($Xl, $this->_P[$i]); > $Xl = $this->binxor($this->binxor($this->_S[0][($temp>>24) & 255] + > $this->_S[1][($temp>>16) & 255], 155c164 < $this->_S[3][$temp & 255]) ^ $Xr; --- > $this->_S[3][$temp & 255], $Xr); 158,159c167,168 < $Xr = $Xl ^ $this->_P[16]; < $Xl = $temp ^ $this->_P[17]; --- > $Xr = $this->binxor($Xl, $this->_P[16]); > $Xl = $this->binxor($temp, $this->_P[17]); 173,175c182,184 < $temp = $Xl ^ $this->_P[$i]; < $Xl = ((($this->_S[0][($temp>>24) & 255] + < $this->_S[1][($temp>>16) & 255]) ^ --- > $temp = $this->binxor($Xl, $this->_P[$i]); > $Xl = $this->binxor($this->binxor($this->_S[0][($temp>>24) & 255] + > $this->_S[1][($temp>>16) & 255], 177c186 < $this->_S[3][$temp & 255]) ^ $Xr; --- > $this->_S[3][$temp & 255], $Xr); 180,181c189,190 < $Xr = $Xl ^ $this->_P[1]; < $Xl = $temp ^ $this->_P[0]; --- > $Xr = $this->binxor($Xl, $this->_P[1]); > $Xl = $this->binxor($temp, $this->_P[0]); Matthew, would it be possible to fix it for a new release please?

Hi, Philippe, I did what you said and run the tests on windows and linux but they failed: Notice: Undefined offset: 2 in D:\dev\tools\php-5.0.4\PEAR\Crypt\Blowfish.php on line 215 It's where i've replaced unpack by your _unpackN2 I don't have 64-bit machine so no tests.

I checked out the last sources on CVS and use them to update my local pear install. I launched then the tests with 'pear run-tests' but they failed on windows and linux. I also tried to use this new version with my code but it failed too. So I'm sorry to say that but it seems that the last commit has not been tested (it should work on windows at least). Or maybe I miss something? I trust you when you say the solution with binxor() is a performance killer. But in my case, it's not so important (well, for now ...).

Good news, the latest sources from CVS work on my windows and my linux !! You've made a good job, thanks! I can't tell you about 64-bit machine because I don't have such a machine, sorry. I'm looking forward to the next release.

I don't know if this helps, but I used this trick to keep away the 4-byte int values to type cast upward to 8-byte ones: function intAdd($a, $b) { if (($a & 0x80000000) == ($b & 0x80000000)) { return (($a & 0x7fffffff) + ($b & 0x7fffffff)); } else { return (($a & 0x7fffffff) + ($b & 0x7fffffff)) + 0x80000000; } } And in _encipher and _decipher functions the $Xl is calculated like this: $Xl = $this->intAdd( ( $this->intAdd( $this->_S[0][($temp>>24) & 0x0ff], $this->_S[1][($temp>>16) & 0x0ff] ) ^ $this->_S[2][($temp>>8) & 0x0ff] ), $this->_S[3][$temp & 0x0ff] ) ^ $Xr;

I have similar problem. First mashine - 64 bits CPU - use Blowfish for encoding some "secret" information. Second machine - 32 bits CPU - use the same Blowfish for decoding "secret" information, but with bad result. Problem is with ^ operator. 64 bit CPU has longer integer type. What can I do? I have tried binxor but with no results.

It seems to me the proper fix is to take advantage of the fact that PHP's bitwise operators work on strings, and use strings instead of inadequate integers. That would probably also be a much better performer than the other suggested fix.