DES encryption using CryptoAPI's

[m.terrier]

I'm working in VC++ 6 and trying to encrypt a string using just plain old DES. The code encrypts the string ok, but its not the correct value I should be getting.

I'm using this DES calculator to check my output and it is where the correct output came from and from other sources I know it is valid. I already have some other code that works for des encryption but I wanted to see if this is possible.

http://www.adfa.oz.au/~lpb/src/DEScalc/DEScalc.html

Input: 3031323334353637 // "01234567"
Key: 74657374696E6731 // "testing1"
Correct out: e1f077a034ebdf8e
Output CryptoAPI's give: ceae0b0456d90e0d

Not sure whats going wrong. I was told by someone else it might be doing authentication and not actual encryption. Any info would be appreciated!

void crypto_wrapup() {
    if(hCryptProv) CryptReleaseContext(hCryptProv, 0);
    hCryptProv = 0;
}


BOOL DES_Encrypt(LPBYTE bData, LPBYTE bKey, DWORD dwKeyLen ){
	if(!CryptCreateHash(hCryptProv, CALG_MD5, 0, 0, &hHash))  // Create a hash object.
		return FALSE;
	if(!CryptHashData(hHash, bKey, dwKeyLen, 0))  // Call CryptHashData.
		return FALSE;
	if(!CryptDeriveKey(hCryptProv, CALG_DES, hHash, KEY_LENGTH, &hDESKey))
		return FALSE;
	if(!CryptEncrypt(hDESKey, 0, FALSE, 0, bData, &dwKeyLen, 8)) // correct value: e1f077a034ebdf8e
		return FALSE;
	return TRUE;
}

int main(int argc, char *argv[])
{
	printf("Crypt Test\n\n");
    
	if(crypto_startup()){
		BYTE  bKey[9] = { 0x74, 0x65, 0x73, 0x74, 0x69, 0x6E, 0x67, 0x31, 0x00 };  // Encryption/Decryption Key  ; 74657374696E6731
		BYTE bData[9] = { 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x00 };  // Data to be Encrypted       ; 3031323334353637
		DWORD dwDataLen = 8;  // Size of Key 
		DES_Encrypt(bData, bKey, dwDataLen);	
	}
	return 0;
}

[hankdane]

Shouldn't the "Final" parameter to CryptEncrypt() be TRUE?

The code looks like it takes all defaults for parameters such as initialization vector, padding, mode, salt, etc. These are all determining factors in what the final ciphertext will be. I don't know how you determine what out is considered 'correct,' as it depends on the parameters. The nature of encryption is such that a slight change in a parameter will lead to a very different result.

[m.terrier]

I thought that as well, but when I set it to TRUE it does nothing.

I'm using that java applet as what should be the correct output. Basically the standard DES encryption of a block of 8 bytes.

I've tinkered with other parameters and still haven't gotten it to work.

Sigh.

[hankdane]

Yes, getting two different modules to encrypt in the same way really can be frustrating, especially when the two modules are written in different languages. I've had to do that before, aligning encryption and hashing in Java and C++, and it's tricky -- but possible.

That said, I noticed that you use MD5 for hashing the key. Why is that? Do you know for a fact that the Java applet uses MD5? I've gotten inconsistent inter-language results with MD5 before, to the point where I've chosen just a simple CRC instead, in places where a strong hash is not required.

You cannot guess at the parameters, such as block size, padding, etc. You must look at the code on the other side and duplicate the values exactly. This, again, can get tricky, because data types often mean different things in different languages.