0

I'm hitting a brick wall, I hope someone can help. I have to encrypt a string that will be decrypted somewhere else (not under my control), as part of an authentication mechanism.

I'm told it uses a cipher "AES/ECB/PKCS5Padding", and I was given a 128 bit encryption key. After implementing this in C#, it doesn't match the expected output.

While poking around a .jar I got my hands on, it seems that the encryption key is used in a different way than I was expecting, and I haven't figured out how, or even if it can, be ported to C#. Java:

   String secretKey = "1234567890abcdef" //example
   KeyGenerator keyGen = KeyGenerator.getInstance("AES");
   SecureRandom sRandom = SecureRandom.getInstance("SHA1PRNG");
   sRandom.setSeed(secretKey.getBytes("UTF-8"));
   keyGen.init(128, sRandom);
   SecretKey generatedKey = keyGen.generateKey();
   byte[] encodedKey = generatedKey.getEncoded();
   SecretKeySpec realKey = new SecretKeySpec(encodedKey, "AES");
   Cipher cipherInstance = Cipher.getInstance("AES/ECB/PKCS5Padding", "SunJCE");
   cipherInstance.init(1, realKey); 
   String encryptedText bytesToHexString(cipherInstance.doFinal("text to encode".getBytes("UTF-8")));

I think I've got it all down except generating the encodedKey above.

Can someone shed some light please? :)

EDIT: The example above should produce 4a031f9da16717d442c0d06c415435b5 I believe.

ByteJunk
  • 1
  • 1
  • It' s not clear to me if the posted Java code is related to the Java code that will be used for decryption. If not, it is not helpful. If it is allowed to post plaintext, key and expected ciphertext, you should do so. Also post your C# code (and ideally the Java code for encryption/decryption, which is probably not possible). – Topaco Sep 09 '20 at 09:56
  • Hi @Topaco! The key and text to encode can be assumed to be the ones I posted, since they won't be constant anyway. The ciphertext output in C# should match what the java code above produces: ```4a031f9da16717d442c0d06c415435b5``` – ByteJunk Sep 09 '20 at 10:00
  • OK, you want to port the above code to C#, i.e. `SHA1PRNG` should be used for key derivation. Then this [answer](https://stackoverflow.com/a/24125677/9014097) should be interesting. What you are trying to do seems to be problematic even within the Android/Java world, so it might be even more problematic when porting to C#. – Topaco Sep 09 '20 at 10:15
  • That's my fear @Topaco, that using the key as a seed for some java implementation of an RNG generator would not be portable... Unfortunately I have zero control over the java side of things. – ByteJunk Sep 09 '20 at 10:26
  • 2
    Here is the link to Java 11 Sun SecureRandom-code, maybe it is of help for you when trying to convert the function to C#: https://java-browser.yawk.at/java/11/java.base/sun/security/provider/SecureRandom.java#sun.security.provider.SecureRandom – Michael Fehr Sep 09 '20 at 10:32
  • You should also keep in mind that even a successful implementation is probably not robust. A future change on one side or the other may possibly result in incompatibility. – Topaco Sep 09 '20 at 10:58
  • I agree with both commenters. To implement, use the source as the algorithm is not clearly specified anywhere (it seems, I haven't found it and I have searched long and hard). Then *migrate away as fast as possible*. Using an random number generator as KDF is a really really really bad idea and has resulted in loss of data. – Maarten Bodewes Sep 13 '20 at 22:14
  • Note that that piece of code seems to be a hodge podge of bad practices. A string as secretkey, the seeded secure random as key generator which may / will fail, the conversion to a "real key" with the exact same contents, the use of ECB, the specification of the SunJCE provider explicitly, the use of "1" instead of the cipher constant. That's quite a few issues right there. At least the encoding part seems correct, I give you that, although base64 would be more efficient than hex. And `bytesToHexString` is a clear name too. – Maarten Bodewes Sep 13 '20 at 22:18
  • Heya @MaartenBodewes, thanks for the input. I can't do anything about the java implementation, and the Powers Above decided to just interact with the jar to get the encoded password instead of rolling out a C# implementation. It's a nightmare... – ByteJunk Sep 14 '20 at 13:10
  • Well, fortunately C# and Java are not that different. Lift the code and implement or try and find an implementation. – Maarten Bodewes Sep 14 '20 at 14:19

0 Answers0