title: AES 128 DOT NET and Java Compatibility
body: <p>We have been trying a prototype of a scheme where we encrypt decrypt data between two systems: One in .NET and the other in Java. We were going to use simple 128 bit AES Encryption.</p>
  
  <p>The problem I am facing is trivial, but I cannot find a proper solution. Maybe my understanding of AES or Encryption in general is less.</p>
  
  <p>Assuming we have a predefined key, represented by the following hex string: "9c361fec3ac1ebe7b540487c9c25e24e".
  This is a 16-byte key.
  The encryption part in Java would be</p>
  
  <pre><code>  final byte[] rawKey = hexStringToByteArray("9c361fec3ac1ebe7b540487c9c25e24e");
    final SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES");
    // Instantiate the cipher
    final Cipher cipher = Cipher.getInstance("AES");
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
  
    final byte[] encrypted = cipher.doFinal(plainText.getBytes());
  </code></pre>
  
  <p>The 'hexStringToByteArray' function converts the hex string to a byte array. The problem is that in java, bytes are signed. So the value 9C is -100 and not 156 (as it would be in .NET).</p>
  
  <p>In Java this becomes: <code>-100,54,31,-20,58,-63,-21,-25,-75,64,72,124,-100,37,-30,78</code></p>
  
  <p>In .NET however, this is: <code>156,54,31,236,58,193,235,231,181,64,72,124,156,37,226,78</code></p>
  
  <p>Question:
  Given that the representation of the keys itself differs, would it affect the encryption process itself?
  This is simple encryption without CBC and PADDING.</p>
  
  <p><strong>Edit:</strong> Updated the code to look formatted.</p>