DES encryption in Java vs .NET - why different?

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?

If you are encrypting this data because you need security and you require using a version of DES, I would go with TripleDES which is 168 bit, instead of standard DES which is 56 bit. Standard DES is simply too easy to be cracked if you have data which needs to be secure for any reason. — FreeAsInBeer, May 19 '11 at 15:46

score 2 · Answer 1 · edited May 23 '17 at 10:34

2

From MSDN:

The IV property is automatically set to a new random value whenever you create a new instance of one of the SymmetricAlgorithm classes or when you manually call the GenerateIV method. The size of the IV property must be the same as the BlockSize property.

So it seems to me that you can simply change the BlockSize property, and you can then set the IV to whatever size you need.

EDIT

From what I have gathered in my research, it seems that all implementations of the DES encryption algorithm use 8 bytes (64 bits, 8 of which get thrown away, leaving you with 56 byte). TripleDES (3DES) allows for a key of 24 bytes (or 192 bits, 24 of which get thrown away, leaving you with 168 bits).

It seems that you will either need to use a TripleDES algorithm in Java (several libraries are available, example, SO Question), or you will need to re-encrypt your data using the regular DES encryption algorithm in .NET.

edited May 23 '17 at 10:34

Community

1
1

answered May 19 '11 at 11:52

FreeAsInBeer

12,937
5
50
82

@Shaul - I think his point was that you can change the .NET implementation to use an 8 byte IV and then the Java approach will have what it wants. – Tim May 19 '11 at 12:02
@Tim - .NET is what it is; I can't change that, and besides, we already have encrypted data that we now need to be able to decrypt in Java. – Shaul Behr May 19 '11 at 12:03
OK, well then that won't work, but it wasn't clear from your original post that you couldn't change the .NET implementation and/or that the data was already encrypted. – Tim May 19 '11 at 12:06
@Tim - quote: "And how can I decrypt something that was encrypted using a 24-byte init vector?" – Shaul Behr May 19 '11 at 12:07
@Shaul, it's not worth arguing semantics. Clearly someone could have read your question a different way because both FreeAsInBeer and I did. I'll see what I can dredge up to actually answer your question. – Tim May 19 '11 at 12:09
@Tim - I don't mean to be unappreciative, sorry. And thanks in advance for whatever help you can give! – Shaul Behr May 19 '11 at 12:18
Shaul - You need to implement 3DES in Java. You currently implemented it in .NET despite what you might think is the case ( based on the fact the vector is 24 bytes ). – Security Hound May 19 '11 at 13:23

score 2 · Accepted Answer · edited May 23 '17 at 12:34

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.

You genius, you! I truncated the byte array to 8 bytes, and it works perfectly! THANK YOU! — Shaul Behr, May 19 '11 at 15:05

score 0 · Answer 3 · answered May 19 '11 at 12:31

Have you taken a look at the Bouncy Castle library for Java? I can't tell from their (very sparse) documentation and samples, but it seems like a widely used library so I'd hope it'd be that flexible. Worth taking a look at least if you haven't already.

DES encryption in Java vs .NET - why different?

3 Answers3