Coldfusion Encrypt() with Blowfish differs from Blowfish encryption in PHP and other languages

Unfortunately, that's not something I can do - we don't have PHP available in our environment.

Maybe someone can help me understand what the issue is here.  If it's the same "blowfish" algorithm outputing in the same format (hex), shouldn't the result be the same?

> If it's the same "blowfish" algorithm outputing in the same format (hex), shouldn't the result be the same?

I don't know about blowfish specifically, but most algorithms allow you to different parameters (IV, Salt and/or iterations). So even if two programs are using the same algorithm, if they're using different parameters they might produce totally different results.  

Do you know what parameters PHP uses for its implementation?

... BTW: My guess would be php is using an IV (see initialization vector in livedocs).  If that actually is the case, you have to modify the CF code to use an IV that matches whatever one is used by php.  Unfortunately, I have no idea what that is.

Nope - php isn't using an IV or Salt, and the mode is the same (ecb).

Hm, well they're doing something different.  Do you have a link to the API?  

Here's what they say in the API

    * Encoding algorithm: blowfish
    * Encoding mode: electronic codebook (ecb)
    * All requests must be encrypted using the Interface Key as the encryption key.
    * Encrypted requests must be encoded in hexadecimal format. For example, the 2 binary bytes \xDF\xA8 are encoded as DFA8 using 4 ASCII characters.
    * If the size of the data is not n * blocksize, the data must be padded with '\0'.

Do you know how to do the last part in CF?  I've tried, but I'm not sure if I'm doing it right.  (Either way, the padding should only affect the last few characters, right?  Even the first few characters of my result is different from the PHP result)

> * Encoding mode: electronic codebook (ecb)

    I am assuming the default encoding mode for Blowfish is ECB, but I'm not 100% sure that is true.

> If the size of the data is not n * blocksize, the data must be padded with '\0'

    Yes, using URLDecode("%00") is the right way to produce the null character (ie "\0").  

>  the padding should only affect the last few characters, right

    No, I wouldn't assume that at all.  Having that predicatable a result would seem to defeat purpose of
    encryption (ie make it easily crackable). Granted that is just IMO.  You'd have to read the actual specs of the  
    algorithm.
   
>  For example, the 2 binary bytes

    That is interesting.  They say "binary" bytes.  Somewhere in the back of my mind I seem to remember
    reading something about a difference between php's encoding and CF's?  Something to do with the php
    functions working with bytes as opposed to strings (as in CF), which resulted in a difference between php
    and CF's output.  Let me search around and see if I can find the reference I'm thinking of.

to confirm, yes - coldfusion's blowfish default is ecb

regarding n*blocksize - this means the length of the string needs to be a multiple of 8, right?  and then I would need to add as many URLDecode("%00") characters to then end of the string as are needed to make the length a multiple of 8?

please let me know if you find anything on this.  thanks for the help.

I looped through adding one padding character at a time to the end of my text string to test what happens to the result of the encryption.  only the last few characters of the encrypted string changed at all - the beginning of the string was exactly the same.

so basically, it seems that the padding is not the issue (or at least not the primary issue) since the result of the encryption between between coldfusion and php differs right from the start.

> For example, the 2 binary bytes

Unfortunately, I think I'm interpreting that statement incorrectly.  It says "Encrypted" requests (ie the output, not the input).  

Do you have the source or just the API?

just the api...and the result that they're expecting, which is the same result when you plug the text into this tool.

http://webnet77.com/cgi-bin/helpers/blowfish.pl  

Unfortunately, if you don't have access to the source, I really don't know how you will be able to figure out the differences.  

OK - I got my hands on the PHP function that's used to encrypt - here it is

function encrypt($data, $key, $alg = "blowfish", $mode = "ecb", $iv = "00000000") {
if (false === ($td = @mcrypt_module_open($alg, "", $mode, ""))) {
throw new Exception("Can not initialize the encryption module!", ENCRYPTION_ERROR);
}
if (@mcrypt_generic_init($td, $key, $iv)) {
throw new Exception("Encryption error!", ENCRYPTION_ERROR);
}
$data = @mcrypt_generic($td, $data);
@mcrypt_generic_deinit($td);
@mcrypt_module_close($td);
$data = @unpack("H*", $data);
return $data[1];
}

Umm... are they using an IV?

no - just the key and the text

I'm not great with php code, but it doesn't look like that shows how the encryption is done, or even the data types involved.

Have you tried encrypting it using java directly to see if you get the same results? If you do and have access to createObject("java", ...) you could use that instead.

I know that Java, PHP, .NET and Delphi all produce exactly the same result for algorithm=BLOWFISH, mode=ECB, encoding=HEX.  The API I need to post to has libraries for all of them, but none for Coldfusion, which is why I need to write the functions myself.

So yes, theoretically that might work, but I have no clue how to use createObject("java", ...).   Can you help?

Yes.  Do you happen to have a java example handy? If not, I can hunt one down.

IT WORKED!!  You rock!  Thanks for sticking with me on this one.  I had almost given up myself.

You are very welcome. I wish I'd thought of it sooner.  I can totally appreciate how frustrating this kind of thing can be!

BTW - You might want to fill out a possible bug report @ Adobe ... 'cause I still can't figure out why the heck the results are different.  Despite trying all kinds of values, settings, padding, etc..

I'll give it a shot, but I'm not sure they'll consider it a bug since it seems to encrypt<->decrypt in coldfusion just fine, just not compatible with the output everywhere else - they may even consider it a security "feature" :)

Great.  I think we could all do without "features" like that ;-)  Even if they could explain why the results are different, that would be helpful.  I mean CF does run on top of java, so I'd expect they're using something like the example above internally anyway.  Well.. at least there's a work-around for now!

Hey - one last question - to decrypt the data coming back from the API I need to use the same algorithm in reverse.  What's the reverse of the BinaryDecode function?

<cfset Cipher = createObject("java", "javax.crypto.Cipher")>
<cfset decryptor = Cipher.getInstance("Blowfish/ECB/NoPadding")>
<!--- must convert the key string into a KeySpec object first --->
<cfset keySpec = createObject("java", "javax.crypto.spec.SecretKeySpec").init(myKey.getBytes(), "Blowfish")>
<!--- initialize the cipher for encrypting --->
<cfset decryptor.init(Cipher.DECRYPT_MODE, keySpec)>
<!--- do the decrypt --->
<cfset decryptedTextFromJava = decryptor.doFinal(returnText.getBytes())>

                                              

1:
2:
3:
4:
5:
6:
7:
8:

I would just create a string and let it do the conversion.  Note, I replaced your setting with "PKCS5Padding" to match my local example.

<cfset Cipher = createObject("java", "javax.crypto.Cipher")>
<cfset decryptor = Cipher.getInstance("Blowfish/ECB/PKCS5Padding")>
<!--- must convert the key string into a KeySpec object first --->
<cfset keySpec = createObject("java", "javax.crypto.spec.SecretKeySpec").init(myKey.getBytes(), "Blowfish")>
<!--- initialize the cipher for encrypting --->
<cfset decryptor.init(Cipher.DECRYPT_MODE, keySpec)>
<!--- do the decrypt --->
<cfset decryptedTextFromJava = decryptor.doFinal(BinaryDecode(encryptedText, "HEX"))>
<cfset decryptedText = createObject("java", "java.lang.String").init(decryptedTextFromJava)>
<cfoutput>
	decryptedText = #decryptedText#<br>
</cfoutput>
                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:

> decryptedTextFromJava

... Not that it really matters :)  but I could have chosen a more accurate variable name there.  Cipher.doFinal(...) returns BYTES not text.

Brilliant!  Thanks again for all your help with this.