Triple Des codes returning cipher with different lengths

I have got this code from Server guys:

public string Encryption(string PlainText)
{
string key = "twelve_digit_key";
TripleDES des = CreateDES(key);
ICryptoTransform ct = des.CreateEncryptor();
byte[] input = Encoding.Unicode.GetBytes(PlainText);
byte[] buffer = ct.TransformFinalBlock(input, 0, input.Length);

return Convert.ToBase64String(buffer);
}

static TripleDES CreateDES(string key)
{
 MD5 md5 = new MD5CryptoServiceProvider();
 TripleDES des = new TripleDESCryptoServiceProvider();
 des.Key = md5.ComputeHash(Encoding.Unicode.GetBytes(key));
 des.IV = new byte[des.BlockSize / 8];
 return des;
}

This is my code against above :

 public String encryptDES(String message) throws Exception {
    final MessageDigest md = MessageDigest.getInstance("md5");
    final byte[] digestOfPassword = md.digest(getNativeKey3().getBytes("utf-8"));
    final byte[] keyBytes = Arrays.copyOf(digestOfPassword, 24);
    for (int j = 0, k = 16; j < 8; ) {
        keyBytes[k++] = keyBytes[j++];
    }

    final SecretKey key = new SecretKeySpec(digestOfPassword, "DESede");
    final IvParameterSpec iv = new IvParameterSpec(new byte[8]);
    final Cipher cipher = Cipher.getInstance("DESede/CBC/PKCS7Padding");
    cipher.init(Cipher.ENCRYPT_MODE, key, iv);

    final byte[] plainTextBytes = message.getBytes("utf-8");
    final byte[] cipherText = cipher.doFinal(plainTextBytes);

    return Base64.encodeToString(cipherText, Base64.DEFAULT)
        .replace("\n", "")
        .replace("\r", "");
}

Problem :

First Code gives below result :

• Encrypted Text for 121212 is VvRQkSUj5SQ69mGXsL+h6w==

But Second Code returns this :

• Encrypted Text for 121212 is 2STVJSd1mnw=

Observations :

• When I increase the plainttext to 10 digits I am getting 24 digit cipher text

Can any one help me in this:

Thanks in Advance

You've been fooled by the badly named Unicode class, which actually specifies UTF-16LE rather than UTF-8.

You can use StandardCharsets.UTF_16LE for specifying the encoding rather than the string; this saves you from one exception to handle.

If there are still issues with the length (test!) then you may have to deal with the Byte Order Mark or BOM - but I don't think so.