0

I'm using this code in Java to generate the cipher text using simple AES algorithm:

public String encrypt(String message, String key) {
    skeySpec = new SecretKeySpec(HexUtil.HexfromString(key), "AES");
    cipher = Cipher.getInstance("AES");
    cipher.init(1, skeySpec);

    byte encstr[] = cipher.doFinal(message.getBytes());
    return HexUtil.HextoString(encstr);
}

And the function HexfromString is:

public static byte[] HexfromString(String s) {
    int i = s.length();
    byte[] byte0 = new byte[(i + 1) / 2];
    int j = 0;
    int k = 0;
    if (i % 2 == 1) byte0[k++] = (byte) HexfromDigit(s.charAt(j++));

    while (j < i) {
         int v1 = HexfromDigit(s.charAt(j++)) << 4;
         int v2 = HexfromDigit(s.charAt(j++));
         byte0[k++] = (byte) (v1 | v2);
    }
    return byte0;
}

I wrote the following code in Golang to mimic the above result.

func EncryptAES(secretKey string, plaintext string) string {
    key := hex.DecodeString(secretKey)
    c, err := aes.NewCipher(key)
    CheckError(err)

    out := make([]byte, len(plaintext))
    c.Encrypt(out, []byte(plaintext))
    return hex.EncodeToString(out)
}

But the issue is that the []bytes key returned from hex.DecodeString() is in unsigned Int where as in Java, the result is in signed Int. And obviously, the encrypted text results are also different, even though every input is same.

IshduttT
  • 179
  • 1
  • 14
  • `Cipher.getInstance("AES")` uses provider dependent default values for mode and padding (e.g. for the SunJCE provider ECB and PKCS#5 padding). Therefore it's not clear from the Java code which mode and padding should be used. Please clarify this. – Topaco Sep 05 '22 at 15:16
  • Also note that ECB is insecure and should not be applied. Furthermore, crypto/cipher (probably due to the security issue) does not support ECB directly. Your Go code only implements the AES primitive, so only a 1 block plaintext (16 bytes) is encryptable. Is this intended? – Topaco Sep 05 '22 at 15:22
  • I'm just using simple AES with the default configuration. And this is the complete code. – IshduttT Sep 05 '22 at 15:34
  • There is no *absolute* default configuration on the Java side, because mode and padding are provider dependent. So, what mode and padding are you using in the Java environment? Probably ECB and PKCS#5 padding, but you should confirm that before porting. If you can't answer that, post sample data: message, key, ciphertext. – Topaco Sep 05 '22 at 16:04
  • S. [here](https://stackoverflow.com/questions/24072026/golang-aes-ecb-encryption) for ECB (this is for decryption, but the gist should be clear from this) and e.g. here for [PKCS7#/PKCS#5 padding](https://pkg.go.dev/github.com/zenazn/pkcs7pad). – Topaco Sep 05 '22 at 17:17
  • I'll check this thing. But my major concern is the key, which is passed to generate CipherBlock. They are different since in golang, it accepts unsigned Integer, while in the java code, it is in signed Integer. – IshduttT Sep 06 '22 at 04:35
  • 1
    Depending on the data type, the same byte sequence can represent different values, e.g. 1000 0000 is for signed -128 for unsigned 128. This is not an error. The key is represented by the byte sequence, not by the representation as signed or unsigned. Whether there is a bug in the Java code with the Hex encoding can not be said, because the code is posted incomplete. Various functions are missing, e.g. `HexFromDigit()`, `HextoString()`,... but you can debug and check this yourself. – Topaco Sep 06 '22 at 05:22

0 Answers0