Decryption - Arrgghh!

[Guest]

I'm having some difficulty trying to decrypt some passwords to move from one application to another [using different encryption] ... can anyone help with this

<cfscript>

rc4key = '823hjdFD00fQFSDFJweru87fsj34FS'; // plain text encryption key

passhex = '668413106F51AB'; // hex encoded password [should return test123]

EncryptedPassword = ToBase64(BinaryDecode(passhex, "Hex"));

writeoutput(EncryptedPassword); // returns ZoQTEG9Rqw==  which is base64 ?!?!?

DecryptedPassword = Decrypt( EncryptedPassword, rc4key, 'RC4','Hex'); //throws an error

writeoutput(decrypted); 

</cfscript>

And the error I get is:

An error occurred while trying to encrypt or decrypt your input string: '' Can not decode string "823hjdFD00fQFSDFJweru87fsj34FS"..

I just don't know what is not happening here, I've tested the key and password at http://crypto.hurlant.com/demo/ and gotten what I expect are correct results....  see attached.....

can anyone help?

-sean

[12Robots]

Not RC4 as the seed, RC4 as the key.

Jason

[-__cfSearching__-]

Yes, if it were really doing RC4 encryption it would be the key. But since that snippet is doing CFMX_COMPAT, the string "RC4" is just used as the seed. At least that is how I have always understood CFMX_COMPAT to work.

ie. This snippet

#encrypt("killbill","RC4")#

... and not

#encrypt("killbill", key, "RC4")#

Message was edited by: -==cfSearching==-

[nealb]

cfSearching -

<cfscript>
    // convert plain text key to base64
    rc4key = '823hjdFD00fQFSDFJweru87fsj34FS';
    keyBytes = charsetDecode(rc4key, "utf8");
    keyBase64 = BinaryEncode(keyBytes, "base64");

    //encrypt it and return value as HEX...
    encrypted = Encrypt("test123", keyBase64, 'RC4', 'hex');
    WriteOutput("encrypted="& encrypted &"<br>");

    // decrypt value
    decrypted = Decrypt( encrypted, keyBase64, 'RC4', 'Hex');
    WriteOutput("decrypted="& decrypted &"<br>");
</cfscript>

I ran your snippet above on my CF 8 Standard Server and received the following error:

The key specified is not a valid key for this encryption: Illegal key size or default parameters.
Use the generateSecretKey method to generate a valid key for this operation.

Perhaps this is a CF Standard vs. Enterprise issue?

The doc says that RC4 is not installed on Standard by default.

The strange thing is that on Standard, this does work:

<cfset testkey = GenerateSecretKey("RC4")>

<cfset encrypted = Encrypt("test123", testkey, 'RC4', 'hex');

[-__cfSearching__-]

>> <cfset testkey = GenerateSecretKey("RC4")>

Did you install the unlimited strength files? I tested the code with the CF9 developer addition and the two changes I made were

http://kb2.adobe.com/cps/546/e546373d.html

- Add bouncy castle as a security provider and

- Installing the unlimited strength files

Message was edited by: -==cfSearching==-

[12Robots]

I tested the original code with CF9 Developer edition, and with some minor changes to the code, it worked fine.  The original poster was doing more conversion than was needed.

<cfscript>

rc4key = toBase64('823hjdFD00fQFSDFJweru87fsj34FS');

passhex = '668413106F51AB';

DecryptedPassword = Decrypt( passhex, rc4key, 'RC4','HEX');

writeoutput(decrypted);

</cfscript>

I did not need to add any additional crypto libs or providers.

I do not have a copy of CF Standard to test this on, but if there is not a provider included in CF Standard or the JVM you are running it on that includes RC4, then you may need to install one. Although, it looks to me like RC4 is standard with Java JCE (which is now a standard part of the JDK).

The ColdFusion encrypt docs are a little misleading, I think.  When it is referring to the algorithms that are included with Enterprise vs. Standard, it is referring to the BSafe Crypto-J library that is licensed for use and included with Enterprise. It then mentions the other algorithms that are only included with Standard.  This does NOT mean that these are the onyl algorithms availabel in Standard, they are just the only ones included.

But since ColdFusion sits on Java, and tje JVM has included the JCE for some time, there are many other providers available to you. I'm not sure about Standard, but the developer edition has 11 of them.

Try this out to see:

<cfdump var="#createObject("java", "java.security.Security").getProviders()#">

I'd say there is a good chance that there is a provider in standard that has RC4 available. And, if there really isn't one, then adding BouncyCastle as a provider is not terribly difficult.

http://www.bouncycastle.org/wiki/display/JA1/Provider+Installation

You can do it at runtime with the same Security object I used above, using the addProvider() method. Or you can add it through config as outlined int he above link.  Either way, you need to add the provider files to your class path.

[-__cfSearching__-]

with some minor changes to the code, it worked fine.  The

original poster was doing more conversion than was needed.

Good catch. I thought I had tried that, but I guess not ..

12Robots wrote:

..you may need to install one. Although, it looks to me like RC4 is standard with Java JCE (which is now a standard part of the JDK).

Ah, okay. I added bouncy castle for my test because I was not sure if RC4 was available or not.

I did not need to add any additional crypto libs or providers.

Weird.  With the developer edition I was getting the "..key specified is not a valid key for this encryption: Illegal key size or default parameters." error. That is why I installed the unlimited strength files. After installing those, the code worked.  I do not know much about the settings, but it seemed like there were some limitations in the policy files of my original jars.

ie

permission javax.crypto.CryptoPermission "RC4", 128;

Then again it could be something "wonky" with my setup. I would have to try it on a clean install to be sure.

Message was edited by: -==cfSearching==-

[nealb]

The RC4 function in CFLib worked fine for me using the external key.  The issue that had me pulling my hair out was the when I converted the string result to Base64 with the toBase64 function, it didn't come out correctly.

As it turns out, the toBase64 uses the same encoding of the page that you're on.

I tried the different encodings and toBase64(result,"iso-8859-1") worked fine.

[-__cfSearching__-]

As it turns out, the toBase64 uses the same encoding of the

page that you're on.

Ooh. Yes. That would make a difference. Glad you figured it out. (Though supposedly the docs recommend using BinaryEncode over ToBase64 these days. Not sure why ..)