Android™

Tips on Matching Encryption with another System

See more Encryption Examples

This example provides tips on matching encryption results produced by another system. Android™

// Important: Don't forget to include the call to System.loadLibrary
// as shown at the bottom of this code sample.
package com.test;

import android.app.Activity;
import com.chilkatsoft.*;

import android.widget.TextView;
import android.os.Bundle;

public class SimpleActivity extends Activity {

  private static final String TAG = "Chilkat";

  // Called when the activity is first created.
  @Override
  public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);

    // This example assumes the Chilkat API to have been previously unlocked.
    // See Global Unlock Sample for sample code.

    CkCrypt2 crypt = new CkCrypt2();

    // Let's examine 256-bit AES encryption in CBC mode.
    // CBC mode is Cipher Block Chaining, and it uses an IV (initialization vector)
    crypt.put_CryptAlgorithm("aes");
    crypt.put_CipherMode("cbc");
    crypt.put_KeyLength(256);
    crypt.put_PaddingScheme(0);
    String ivHex1 = "000102030405060708090A0B0C0D0E0F";
    String ivHex2 = "FF0102030405060708090A0B0C0D0E0F";
    crypt.SetEncodedIV(ivHex1,"hex");
    String keyHex = "000102030405060708090A0B0C0D0E0F101112131415161718191A1B1C1D1E1F";
    crypt.SetEncodedKey(keyHex,"hex");

    // Matching encryption requires all of the above settings to be matched exactly.
    // Let's get our output in hex format so we can easily see the values of the encrypted bytes.
    crypt.put_EncodingMode("hex");

    // Encrypt something small:
    Log.i(TAG, crypt.encryptStringENC("Hello"));
    // The result is 5B827AB3B4F9F2292C2B74C8A6C99A3D
    // This 16 bytes -- exactly one AES encryption block.

    // Let's change only the padding scheme.
    crypt.put_PaddingScheme(3);

    // Encrypt again:
    Log.i(TAG, crypt.encryptStringENC("Hello"));
    // The result is entirely different: 469C28CC576069F807891FEE2DE76D68

    // The padding scheme only affects the very last block of output.  Therefore,
    // if all settings match except for the padding scheme, we're unable to
    // know if we encrypt a very small amount of data. However, if we encrypt
    // a larger amount of data, the single difference becomes apparent:
    Log.i(TAG, "-- Only the padding scheme differs --");
    crypt.put_PaddingScheme(0);
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));
    crypt.put_PaddingScheme(3);
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));

    // Now examine the outputs:
    // F6A201F8E0B6595FA20E4A212A2AD9A5046DAF29E8B35AD15CEE56A1A69F2A3A7B347A7C15E26E7A6760533C7A8E0D44
    // F6A201F8E0B6595FA20E4A212A2AD9A5046DAF29E8B35AD15CEE56A1A69F2A3A292CA61D03A85E1AC39B50D4DA71691E
    // We can see the output matches except for the last block, which is affected by the padding scheme.

    // If we are able to easily use ECB mode w/ the other system
    // we are trying to match, then eliminate the IV from the picture.
    // If the encryption matches in ECB mode, but not in CBC mode,
    // then we know all correct except for the IV.
    // For example, you can see how the IV changes everything with CBC mode,
    // but it's not used in ECB mode:
    crypt.put_PaddingScheme(0);
    crypt.put_CipherMode("cbc");
    Log.i(TAG, "-- Only the IV differs, CBC mode produces different output. --");
    crypt.SetEncodedIV(ivHex1,"hex");
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));
    crypt.SetEncodedIV(ivHex2,"hex");
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));

    crypt.put_CipherMode("ecb");
    Log.i(TAG, "-- Only the IV differs, ECB does not use the IV.  The outputs are the same. --");
    crypt.SetEncodedIV(ivHex1,"hex");
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));
    crypt.SetEncodedIV(ivHex2,"hex");
    Log.i(TAG, crypt.encryptStringENC("HelloHelloHelloHelloHelloHelloHello"));

    // If we can eliminate the padding scheme and IV from the degrees of freedom,
    // then the only remaining likely differences are (1) the secret key,
    // and (2) the input data itself.

    // The secret key is composed of binary bytes of exactly KeyLength bits.
    // For 256-bit AES encrytion, the key length is 256, and therefore the 
    // secret key is exactly 32 bytes.  (32 * 8 bits/byte = 256 bits)
    // If the secret key is derived from an arbitrary password string, then one must
    // exactly duplicate the derivation scheme (such as PBKDF2, for example)
    // The input bytes to the derivation scheme must also match.  For example,
    // is it the utf-8 byte representation of the password string that is used
    // as the starting point for the derivation, or perhaps utf-16, or ANSI (1 byte per char)?

    // Likewise, if the data being encrypted is a string, what byte representation of
    // the string is being encrypted?  If the bytes presented to the encryptor are different,
    // then the output is different.

  }

  static {
      System.loadLibrary("chilkat");

      // Note: If the incorrect library name is passed to System.loadLibrary,
      // then you will see the following error message at application startup:
      //"The application <your-application-name> has stopped unexpectedly. Please try again."
  }
}