AES-256, BouncyCastle, Sun Crypto Providers, Default Padding

Question

Hi,
The subject alsmost says it all, but in a nutshell, I would like to use BC for AES-256. I also wanted to compare the ciphered outputs from both BC and SUN to make sure everything was working ok (I have installed the Unlimited Strength Jurisdiction Policy Files 6 for the Sun JRE 6).
I have noticed the following, when the data input is a multiple of 16, the ciphered data generated by both engines are the same (Sun = AES, BC = PaddedBufferedBlockCipher(AES Engine) + PKCS7Padding).
However, when the data input is not of a multiple of 16 - the ciphered output is different.
Hence my question: What is the default padding and mode used by the Sun JCE when doing a getInstance("AES") ?
How to make sure that the ciphered data is the same for both engines, regardless of the data input length pls?
Thx

Answer 1

Hi,
So what is the problem with using the BC provider?
The problem with using the BC provider is that if you have a web started application, the lambda user should not worry about installing an extra set of files for the JRE. And that lambda user might not know at all how to install the policy file as well. (Note that this policy is only required on Windows - works fine on Mac). All of this for AES-256 should be transparent.
Code for Sun JCE
public String encryptToBase64(String data) throws Exception {
          Cipher cipher = Cipher.getInstance(aesCipher); // "AES"
         cipher.init(Cipher.ENCRYPT_MODE, secretKey);
         final byte[] newData = EncryptionUtils.getBytes(data);
         final byte[] edata = cipher.doFinal(newData);
         return Base64.encodeBase64String(edata);
Code for BC Provider works fine (with policy) - same output
Only difference comes from:
Security.addProvider(new BouncyCastleProvider());and
Cipher cipher = Cipher.getInstance(aesCipher, "BC");What I am just trying to do is to use the BC API directly - no provider - so that my AES-256 ciphered output is the same that the Sun and BC provider with policy installed.
I managed to do it - but by padding manually the data myself so that it is a multiple of 16 in length (I would llike to avoid this):
public String encryptToBase64(String data) throws Exception {
          final byte[] newData = EncryptionUtils.getBytes(data);
          return Base64.encodeBase64String(encode(newData));
}     private byte[] encode(byte[] inputBytes) throws Exception {
         final BufferedBlockCipher cipher = getCipher(true);
         final byte[] outputBytes = new byte[cipher.getOutputSize(inputBytes.length)];
         int outputLen = cipher.processBytes(inputBytes, 0, inputBytes.length, outputBytes, 0);
         outputLen += cipher.doFinal(outputBytes, outputLen);
         final byte[] finalBytes = new byte[outputLen];
         System.arraycopy(outputBytes, 0, finalBytes, 0, outputLen);
         return finalBytes;
private BufferedBlockCipher getCipher(final boolean forEncryption) {
          final BlockCipher aesEngine = new AESEngine();
          final BufferedBlockCipher cipher = new PaddedBufferedBlockCipher(aesEngine, new PKCS7Padding());
         cipher.init(forEncryption, new KeyParameter(rawKey));
         return cipher;
}with
public class EncryptionUtils {
     public static final int DEFAULT_BLOCK_SIZE = 16;
     public static final String pad = "                ";
     public static byte[] getBytes(final String str) {
          if (str.length() == DEFAULT_BLOCK_SIZE) {
               return str.getBytes();
          final int padding = 16 - str.length() % 16;
          final int newSize = str.length() + padding;
          return (str + pad).substring(0, newSize).getBytes();
}Apologies if I was not clear.
On top of that - if your code is deciphered on Android for ex, using BC makes sense as I think it is the provider for Android.
thx