Archived Forum Post

Index of archived forum posts

Question:

encryption not working windows to windows

Aug 08 '12 at 16:30

We have an issue where chilkat encryption does not work Windows to Windows with same application. I have a zip file proving all of this which you can add a key to and run, but don't see a way to attach here.

Build the application with QtCreator on Windows XP and click the button you will get the following:

00:25:22:5E:A2:26 QFLdfOIOOYVW4fDxbEo+pvu+WkcCGsApABxZ7sxdIRc=

Import the .PRO file to visual studio 2010 build and run

00:25:22:5E:A2:26 nca3tFYPPqviigXKJ6Slkc7iUn8wc2DZRY3cjoGz7ss=

We chose Chilkat because it was supposed to be cross platform. The backend system uses Visual Studio, but the other platforms are going to be built with QtCreator. We were shocked we couldn't get this to work Windows to Windows.


Answer

I was shocked that you didn't post any kind of sample code (or a link to same) that could reliably reproduce the problem ;)

I kid, but there's not much to go on here unfortunately. If it's the exact same code and library being used in QtCreator and VS2010, then maybe there is something about the environments? Perhaps some assumptions about endianess? Maybe an old version of the librar(y|ies)?


Answer

The topic of matching encryption has been extensively discussed. See this Chilkat blog post: http://www.cknotes.com/?p=430

It's 99.99% likely your app in QtCreator is doing something differently than your app in VS2010. In other words, the various settings for encryption do not match exactly, or maybe the data itself is different. For symmetric encryption algorithms, the following must match exactly:

  1. Algorithm
  2. Key size
  3. Binary secret key
  4. Cipher Mode (CBC, ECB, etc.)
  5. IV (Initialization Vector)
  6. Padding Scheme

Two helpful hints:

  1. Make sure to encrypt enough data so that it results in more than one block of output. The block size for the AES encryption algorithm is 16 bytes, therefore encrypt more than 16 bytes so that if the difference is only in the padding scheme, it will become apparent because only the last block of output is different.
  2. Write sample code to match known answer tests. This example ( http://www.chilkatsoft.com/p/p_160.asp ) shows Chilkat producing the output for an NIST test vector, which also matches the output for doing the same with Java's JCE.

Answer

Since I cannot put this in a response comment.

VS1010

00:25:22:5E:A2:26

nca3tFYPPqviigXKJ6Slkc7iUn8wc2DZRY3cjoGz7ss=

ChilkatLog: EncryptStringENC:

DllDate: Apr 20 2012
UnlockPrefix: IPGHOSCrypt
Username: LOGIKAL-C139927:Roland
Architecture: Little Endian; 32-bit
Language: Visual C++ 8.0
EncryptionParams:
  algorithm: aes
  keyLength: 128
  paddingScheme: 0
  cipherMode: cbc
  encodingMode: base64
  charset: utf-8
  secretKey: 3DCC 1543 00A5 8D9C 0B71 E6AB A756 ED3F
  iv: 
  inDataNumBytes: 17
  inData: 3030 3A32 353A 3232 3A35 453A 4132 3A32 36
--EncryptionParams
Warning: IV length is not equal to the algorithm's block size
blockSize: 16
IV_len: 0
algorithm: aes
keyLength: 128
encryptedData: 9DC6 B7B4 560F 3EAB E28A 05CA 27A4 A591 CEE2 527F 3073 60D9 458D DC8E 81B3 EECB
**Success.**

--EncryptStringENC --ChilkatLog

QtCreator

00:25:22:5E:A2:26

viWn2tyeuKnbFMq3tbruiuxxRV2qmCZR4wNYHdGdP+0=

ChilkatLog: EncryptStringENC:

DllDate: Feb  9 2012
UnlockPrefix: IPGHOSCrypt
Username: LOGIKAL-C139927:Roland
Architecture: Little Endian; 32-bit
EncryptionParams:
  algorithm: aes
  keyLength: 128
  paddingScheme: 0
  cipherMode: cbc
  encodingMode: base64
  charset: utf-8
  secretKey: 4303 33C8 A4FF C024 2274 1933 517B 3B01
  iv: 
  inDataNumBytes: 17
  inData: 3030 3A32 353A 3232 3A35 453A 4132 3A32 36
--EncryptionParams
Warning: IV length is not equal to the algorithm's block size
blockSize: 16
IV_len: 0
algorithm: aes
keyLength: 128
encryptedData: BE25 A7DA DC9E B8A9 DB14 CAB7 B5BA EE8A EC71 455D AA98 2651 E303 581D D19D 3FED
**Success.**

--EncryptStringENC --ChilkatLog


Answer

The LastErrorText proves they are not. You need to do some basic debugging in your source code. Verify the hexKey just prior to calling crypt.SetEncodedKey. Does the hexKey match what is reported in the LastErrorText?

In any case, I can see the error -- which is exactly something I mentioned before -- "a typical cause for differences between the same code on different systems can have to do with uninitialized memory." In this case, you have SALT_VALUE -- which is NOT a null terminated string. Whatever bytes lie beyond the final byte in this array are undetermined -- and left to chance.

   const char SALT_VALUE[] = {'O','D','S','i','u','h','b','f','d','K','J','D','i','o','u','h','d','c','*','#','@','o','u','j','D','N','F','S',';','j','n'};

The call to SetEncodedKey expects a null terminated string. But you are passing SALT_VALUE to it -- which is not a null terminated string, and the bytes that follow it are left to chance -- heck, you could even end up with a hard crash here..