Question

I have the following Java code being used on an Android device that encrypts and decrypts strings using the AES encryption algorithm and an SHA1PRNG hash. I want the Android device to call a .NET WCF service written in C#. I have been searching everywhere trying to find an equivalent in C# that could encrypt and decrypt in a similar way to the Java code, but could not find the exact same way to do it. Here is the Encrypt() method in both languages:

Java:

public static String encrypt(String seed, String cleartext) throws Exception 
{
    KeyGenerator kgen = KeyGenerator.getInstance("AES");
    SecureRandom sr = SecureRandom.getInstance("SHA1PRNG");
    sr.setSeed(seed);
    kgen.init(128, sr); // 192 and 256 bits may not be available
    SecretKey skey = kgen.generateKey();

    byte[] rawKey = skey.getEncoded();
    SecretKeySpec skeySpec = new SecretKeySpec(rawKey, "AES");
    Cipher cipher = Cipher.getInstance("AES");
    cipher.init(Cipher.ENCRYPT_MODE, skeySpec);
    byte[] encrypted = cipher.doFinal(cleartext.getBytes());
    return toHex(encrypted);
}

I have created something similar to this in C#, which also uses AES and SHA1:

C#:

public static string Encrypt(string seed, string cleartext)
{
  var objAesCrypto = new AesManaged();
  var objHashSha1 = new SHA1Managed();

  var byteHash = objHashSha1.ComputeHash(Encoding.ASCII.GetBytes(seed));
  var truncatedHash = new byte[16];
  Array.Copy(byteHash, truncatedHash, truncatedHash.Length);
  objAesCrypto.Key = truncatedHash;
  objAesCrypto.Mode = CipherMode.ECB;

  var byteBuff = Encoding.ASCII.GetBytes(cleartext);
  return Convert.ToBase64String(objAesCrypto.CreateEncryptor().TransformFinalBlock(byteBuff, 0, byteBuff.Length));
}

There are several problems with this, however. As you can see, using C#’s version of SHA1 (SHA1Managed), it returns a hash of 20 bytes, not 16. The only way to get it to pass into the AES algorithm is to truncate the hash to 16 bytes first.

The second problem is, although both work just fine in their respective environments, when I try to pass an encrypted string from Java, along with the seed, the C# code is never able to decrypt it properly. The encrypted strings in both cases look nothing alike and are even different lengths. A typical encrypted string from the Java side looks something like this: F7E8758A2E65518FB49C53BC707288FC (32 chars long). Whereas the same exact encrypted string with the same exact seed from the C# side looks like this: 3VysgnYgNi9OJBxL2FP+rQ== (24 chars long).

I’m sure it has something to do with the fact that I’m truncating the hash in C#, but that doesn’t explain why the two encrypted strings look so vastly different. (Another intersting thing I noticed is that no matter what string and seed I use on the C# side, it’s always 24 chars long and ends with two equal signs – why is that?)

So, my question is, how do I get both environments to be able to decrypt each other’s encrypted strings using the same seed values? I don’t care if I even need to use different algorithms on the C# side than the Java side, I just need the C# code to be able to read the Java-encrypted strings.

Answer 1

The second problem is, although both work just fine in their respective environments, when I try to pass an encrypted string from Java, along with the seed, the C# code is never able to decrypt it properly.

You shouldn’t be trying to decrypt a hash. Hashes are one-way.

A typical encrypted string from the Java side looks something like this: F7E8758A2E65518FB49C53BC707288FC (32 chars long). Whereas the same exact encrypted string with the same exact seed from the C# side looks like this: 3VysgnYgNi9OJBxL2FP+rQ== (24 chars long).

That’s because you’re converting to hex in Java, but to Base64 in C#:

return toHex(encrypted);

vs

return Convert.ToBase64String(...);

As for the seed length issue – again, you’re doing different things in the Java vs the C#. It’s not at all clear to me that using SecureRandom in that way is meant to generate the same secret key as using a straight hash from SHA1.

Rather than trying to fix this approach though, I’d suggest you should be rethinking it – it doesn’t look secure to me at all. What you’ve called a seed is more than just a seed – it’s basically a complete key. An attacker who knows the seed effectively knows the “password” to your system; you might as well just use raw bytes.