0

I am using the following in a RoR project:

somepass =Aes.encrypt_buffer(128, 'ECB', some_cypher_key, nil, pain_string)

Does using this lib and method ECB use padding by default or not?

What I am ultimately trying to do is have a RoR app and a Java app be able to create the same encrypted string out of the same simple string.

In Java code I use: cipher = Cipher.getInstance("AES/ECB/PKCS5Padding", "SunJCE");

These two lines of code do not create the same encrypted key.

BenMorel
  • 34,448
  • 50
  • 182
  • 322
Rafael
  • 1,061
  • 4
  • 16
  • 32
  • I hope you meant that they don't create the same encrypted block instead of same encrypted key? – Milan Apr 15 '11 at 19:02

1 Answers1

1

Aes.encrypt_buffer will use padding, just not that kind that you are expecting. It will pad the block with n bytes with the value of added bytes. That is to say, if it needs to add 15 bytes, it will pad with 0x0f, if it needs to add 5bytes, it will pad with 0x05. That is to say, PKCS7 as described in RFC-5652.

You should switch to openssl or use Cipher.getInstance("AES/ECB/PKCS7Padding", "BC") with java.

Community
  • 1
  • 1
Milan
  • 15,389
  • 20
  • 57
  • 65
  • Thanks Milan. Using PKCS7 padding with provider BC yields same result as when using PKCS5 padding with provider SunJCE. Any idea why is that? Also I've noticed some passwords return a encrypted key with a '-' in front but that is not the case with ruby. Any thoughts? Thanks – Rafael Apr 15 '11 at 16:18
  • Been a while since I last played with pkc standards, but I soon realised that pkcs7 is just an extension of pkc5 that can handle larger blocks. That is why you are getting the same results. As it seems the code you have should work, but it isn't most like due to a faulty standard implementation by ruby-aes. My advice is to switch over to openssl instead and try again. – Milan Apr 15 '11 at 18:58
  • is there any chance that i could be getting these strange keys because i am encoding the bytes from the cipher the wrong way? – Rafael Apr 15 '11 at 19:52