What version of CF do you have?  As far as I know RC4 is not available in the standard edition.  You need either Enterprise or additional providers installed.

Cheers

The following test works. It may contain something for you.

<cfscript>
rc4key = generatesecretkey("RC4");
writeoutput("CF-generated RC4 key: " & rc4key & "<br>");

password = "test123";
EncryptedPassword = encrypt(password,rc4key,"RC4","hex");
writeoutput("Encrypted password: " & EncryptedPassword & "<br>");
DecryptedPassword = Decrypt( EncryptedPassword, rc4key, 'RC4','Hex');
writeoutput("Decrypted password: " & DecryptedPassword);
</cfscript>

sean69 wrote:

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

 

 

ok, soooo the problemis with the key?

 

Indeed, the problem is likely with the key. I would just take Coldfusion's insurance policy,

rc4key = generatesecretkey("RC4");

and then store the value somewhere.

sean69 wrote:

 

wherein lies the problem, I am migrating customers from one store application [Candypress - asp pages] to a completely new application since there is about 9000 of them it would be nice to be able to script the passwords.... [stored as plain text in the new application

No problem. Just let Coldfusion generate the RC4 keys for you.

 

I'm trying to migrate the passwords as well

Ah. That wasn't clear to me. In any case, I doubt whether '823hjdFD00fQFSDFJweru87fsj34FS' is an RC4 key.

It wants to "base64decode" the string.

So... simply send it a base64-encoding of the string.  Let the parameter be a function-call which encodes the actual key so that CF can happily decode it again.

What I'm saying is... I've found that a couple of the crypto functions expect to receive a base64-encoded string.  They croak if they don't get one.

So, if what you've actually got is "the actual string," i.e. not base64-encoded, and you need to pass that string to the function, simply give it what it wants:  let the parameter simply be toBase64(your_known_string).  You hand the function the encoded version of your_known_string so that it can immediately decode it again ... producing your_known_string ... and everybody's happy now.

You may find that an algorithm which accepts an RC4 key expects it to be base64 encoded.  "So," all I'm saying is, "if that is the case, then base64 encode it so that CF can immediately base64 decode it again."  In this way, you pass the necessary string into the function.

That is indeed what I was suggesting.

but ...

are you sure that the fourth parameter to Decrypt() should be 'hex'?  I don't know the answer to that.  Is this supposed to represent the encoding of the data string, or of the key?

Sean -

Did you ever happen to figure this out?  If so, what was the issue?

Thanks,

Neal

Yeah, I gave up as well.  Decided to use this function:

http://www.cflib.org/udf/RC4

Not RC4 as the seed, RC4 as the key.

Jason

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');

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.

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.