2

I received the following data from a vendor so that we can decrypt data on our end.

Algorithm : AES 256bit
Key : test123xxxxxx
Key Length : 32
Initialize Vector: ei8B3hcD8VhnN_cK
Built in methods : YES (From inbuilt class CommonCryptor.h method with variable CCCryptorStatus).

Please note I have no idea if the last line has any relevance to our decryption.

I attempted the following on a sample string that we should be able to decode.

<cfset item = "eLgExhcox5Ro1kPB1OlJP1w6tEJ3x94gM/QJS5dCZkyjEVfNjIid3R7JP4l1WZD1" />

<cfoutput>#decrypt(#item#, #key#, 'AES', 'Base64', #iv# )#</cfoutput>

The error I receive is: The value of parameter 5, which is currently ei8B3hcD8VhnN_cK, must be a class [B value. of which I cannot find anything about.

I am also assuming the encoding is Base64 of which I am finding out from the vendor. Is there anything else I'm missing.

justacoder
  • 2,684
  • 6
  • 47
  • 78
  • May also want to verify the padding scheme they are using. CF defaults to PKCS5Padding, but you can change it if needed via the algorithm string ie "AES/CBC/PKCS5Padding" – Leigh Apr 06 '15 at 16:02
  • I just found out the vendor uses PKCS7 padding. Do I modify the number in the above algorithm accordingly? – justacoder Apr 13 '15 at 12:26
  • The two are equivalent, up to a certain block size. So as long as they are not using a block size greater than 16, PKCS5 should be fine. After that you need to use PKCS7 (not supported by core java, try BouncyCastle) For more details see * http://stackoverflow.com/questions/10193567/java-security-nosuchalgorithmexceptioncannot-find-any-provider-supporting-aes-e * http://crypto.stackexchange.com/questions/9043/what-is-the-difference-between-pkcs5-padding-and-pkcs7-padding – Leigh Apr 14 '15 at 23:51

1 Answers1

2

My guess would be it is complaining that the IV value is not binary. If your IV value is a base64 string, use binaryDecode(yourIVString, "base64") to get the binary value.

a class [B value

The [B refers to the expected object: an array of bytes. Apparently [B is the "binary name [...] as specified by the Java Language Specification (§13.1)". You will see the same thing if you create a byte[] array and dump the class name:

 // show binary and canonical class names
 arr = javacast("byte[]", [1]);
 writeOutput("name="& arr.getClass().name);
 writeOutput("<br>canonicalName="& arr.getClass().canonicalName);

Side note, if you are using a 256 bit key, be sure you have installed the (JCE) Unlimited Strength Jurisdiction Policy Files first. Otherwise, you are limited to 128 bit keys maximum.

Community
  • 1
  • 1
Leigh
  • 28,765
  • 10
  • 55
  • 103
  • I added `binaryDecode(IVString, 'base64')` and now it throws **The input and output encodings are not same.** – justacoder May 19 '15 at 12:31
  • (Edit) Did you change the CF code to use `AES/CBC/PKCS5Padding` instead of just `AES`? Also, did you install the JCE Unlimited Strength files, as noted above (restart required)? – Leigh May 19 '15 at 17:00
  • Yes to `AES/CBC/PKCS5Padding`, no to the JCE since the vendor came back and said it was 128-bit encrypted only. – justacoder May 19 '15 at 17:29
  • Hm... what is the new key size? Do you have a sanitized example with dummy keys you can post? – Leigh May 19 '15 at 21:13
  • Did you ever figure this out? – Leigh Jun 18 '16 at 01:16
  • Wow, what a throwback follow-up. No, I have not. It's fallen to the bottom of the to-do pile since then. – justacoder Jun 19 '16 at 22:43
  • It has only been a year ;-) Just came across this one again and was curious. If it ever makes its way to the top of pile, drop a comment and let me know. Encryption problems are always fun :) – Leigh Jun 20 '16 at 19:37