Encryption in windows - making output change more

[Helium_Junkie]

Hi there, hoping someone can help me with this.
I've been asked to modify an encryption routine for a clients software that uses windows cryptography provider to encode a software licence before distribution.

The problem with the existing code is that the output doesn't "change enough".

For example, the string "Ocuk Rocks" encrypts as "123456789".
The string "OcUK Rokks" encrypts as "123456689", only a very small portion of the resultant text actually changes.

The client would like it if even a tony change in the string resulted in near-total change to the encoded text.

I do not know how to achieve this, and would greatly appreciate any advice

Code uses function chain: CryptAcquireContext, CryptCreateHash, CryptHashData (hashes the hardcoded passphrase), CryptDeriveKey, CryptEncrypt.

Alternatively, any recommended forums for asking this question?
Thankee.

 

[Helium_Junkie]

This has been very helpful, thank you all

 

[Helium_Junkie]

I would typical have a variable IV in the form of a timestamp that is stored with the encrypted data. This does NOT compromise security and will ensure 'uniqueness' of cypher text. Also I would use CBC.

Sorry I'm having a little trouble with this. How could I add a timestamp but not have to send that timestamp to the user for them to decrypt the output?

 

[Helium_Junkie]

Hmm.

Well heres the flow:

CryptAcquireContext gets the CSP (MS_ENH_RSA_AES_PROV)
CryptCreateHash opens a hash object using RC4
CryptHashData hashes a hardcoded password.
CryptDeriveKey uses the hashed password to create an encryption key item (with RC4 specified).
CryptEncrypt uses the key to encrypt the data.

Every time this flow is executed the output is the same, when the data changes slightly the output changes slightly. The first segment of the output seems to never change, one presumes this is a header of some form.

Come time to decrypt, the flow is very similar, except CryptEncrypt is CryptDecrypt. It still creates a key in the same way.

Sorry to be an absolute tard about this, but I lack fundamental understanding of what is wrong in this flow!
Which parts are wrong, where would the initialization vector come into play?

 

[Helium_Junkie]

OK I think I need to use CryptSetKeyParam after the "deriveKey" call to add the IV. Looks like IVs default to zero.
Also can use this to enforce CBC... testing this now.

 

[Helium_Junkie]

I used RC4 on recommendations above, can switch it to a few choices I think (need win2000 supported algs).
Is CALG_3DES (Triple DES) any better?
Basicaly, going with the AES provider I have these choices:

http://msdn.microsoft.com/en-us/library/aa375545(VS.85).aspx

 

[Helium_Junkie]

I really appreciate your help with this, and will embark on that path. I have some more questions though, if that's ok.

So once I've done all that and run the Encrypt function, from the target pc when it receives the encrypted output presumably I then have to retreive the IV from it somehow... And then with the IV I can run through all the same steps and decrypt...

If that's correct, would you happen to know what command retreives the IV?

 

[Helium_Junkie]

Ok, go with AES with 256bit key - CALG_AES_256 and use the hash CALG_SHA_256 to create your key.

From MSDN:
CALG_SHA_256
SHA hashing algorithm. Key length: 256 bits.
*Windows XP and Windows 2000: This algorithm is not supported.

Most of our users are on XP, so I guess this one is out.
There is "CALG_SHA" available though, that any good?

 

[Helium_Junkie]

Well after a couple days of broken computer, I seem to have this working pretty much as you say, and it does indeed cause complete output change when using a randomly generated IV Excellent, thanks very very much! I really appreciate the help!