Question

I have a .NET method for doing DES encryption on a string:

public static string EncryptTripleDES(string value, byte[] encryptionKey, byte[] initializationVector) {
  if (!value.IsNullOrEmpty()) {
    TripleDESCryptoServiceProvider cryptoProvider = new TripleDESCryptoServiceProvider();
    MemoryStream ms = new MemoryStream();
    CryptoStream cs = new CryptoStream(ms, cryptoProvider.CreateEncryptor(encryptionKey, initializationVector), CryptoStreamMode.Write);
    StreamWriter sw = new StreamWriter(cs);
    sw.Write(value);
    sw.Flush();
    cs.FlushFinalBlock();
    ms.Flush();
    //convert back to a string
    return Convert.ToBase64String(ms.GetBuffer(), 0, (int)ms.Length);
  } else {
    return "";
  }
}

As you see, the algorithm takes 2 parameters – an “encryption key” and an “initialization vector”.

Now I need to write a DES encryption/decryption function in Java, paralleling this function, such that if you supply the same encryption key and initialization vector, you’ll be able to decrypt in Java something that was encrypted in C#. (Puts on Java overalls, dusts off about 10 years since last using Java, Googles for DES encryption in Java…)

Found a decent Java DES encryption approach here. But – oh dear, it turns out that this algorithm insists on an initialization vector of exactly 8 bytes; the .NET code uses an init vector of 24 bytes!

Now what? Why does Java insist on an 8-byte init vector? And how can I decrypt something that was encrypted using a 24-byte init vector?

Answer 1

Have you tried using the first 8 bytes of the 24 byte initialization vector in the Java code? Everything I’m seeing through searching and looking at source code indicates that only the first 8 bytes would be used since Triple DES has an 8 byte block size. I’m really surprised that the .NET code doesn’t raise an exception like the one mentioned in this question since the IV doesn’t match the algorithm’s block size. Also, see this question for examples where the 8 byte IV is used successfully.

One additional challenge in the .NET code is that default values are used for the padding and ciphermode. I don’t know what .NET will use for those, although the remarks here indicate that the default ciphermode is CBC. I see no mention of padding, but from the interoperability example here, it seems that CBC and PKCS5Padding will work. I’d hesitate to rely on defaults for interoperability like this though, as they can be problematic.

Coming from a Java background I’m not really sure what is going on in the C# code using a 24 byte IV, but the 8 byte IV enforced by Java seems to be correct to me. I’m always interested in being proven wrong and learning something new though. Bouncycastle as mentioned by @Tim also enforces this same constraint and it seems like .NET usually does also.