login about faq

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.

asked Aug 07 '12 at 14:33

seasoned_geek's gravatar image

seasoned_geek
1111


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)?

link

answered Aug 07 '12 at 23:34

jpbro's gravatar image

jpbro ♦
1.1k2618

I'm leaning more towards a different definition of "cross platform" being used by marketing.

(Aug 08 '12 at 09:20) seasoned_geek

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.
link

answered Aug 08 '12 at 08:53

chilkat's gravatar image

chilkat ♦♦
11.8k316358421

Well, I created a self contained example that I can email to you (provided you are willing to put your own license code in it). I have already emailed it to support@.... It is THE EXACT SAME SOURCE and library tree. Build it in QtCreator and get one answer. Import the .PRO file into Visual Studio 2010, do a clean, and build the exact same source sitting in the exact same place and get different output.

(Aug 08 '12 at 09:09) seasoned_geek

Set the VerboseLogging property = true, and then also examine the LastErrorText on both sides after doing the encryption.

(Aug 08 '12 at 09:44) chilkat ♦♦

Also, a typical cause for differences between the same code on different systems can have to do with uninitialized memory that, by chance, can be different. For example, this is a red flag to me:

    QByteArray instgx = inStg.toUtf8();              //toLocal8Bit();
    const char *instg = instgx.data();
Is the string's null terminator included in the QByteArray? Is the memory pointed to by instgx.data() properly null terminated?

(Aug 08 '12 at 09:56) chilkat ♦♦

Per the easily checked documentation: http://doc.qt.nokia.com/4.7-snapshot/qstring.html http://doc.qt.nokia.com/4.7-snapshot/qstring.html#toUtf8 Returns a UTF-8 representation of the string as a QByteArray.

http://doc.qt.nokia.com/4.7-snapshot/qbytearray.html http://doc.qt.nokia.com/4.7-snapshot/qbytearray.html#data Returns a pointer to the data stored in the byte array. The pointer can be used to access and modify the bytes that compose the array. The data is '0'-terminated, i.e. the number of bytes in the returned character string is size() + 1 for the '0' terminator.

(Aug 08 '12 at 14:02) seasoned_geek

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

link

answered Aug 08 '12 at 14:32

seasoned_geek's gravatar image

seasoned_geek
1111

The secret key's are not equal. Also, no IV has been explicitly specified, which is needed for cipher block chaining (CBC) mode. The IV issue shouldn't matter because Chilkat will default it to all null bytes. However, encrypting with different secret keys will certainly produce different results..

(Aug 08 '12 at 15:56) chilkat ♦♦

The secret keys are physically the same. It is the EXACT same source file being compiled from the EXACT same location. It is hard coded in the program as

const char SALT_VALUE[]

If they are appearing "different" to the library then it is a bug in

const char * hexKey; hexKey = crypt.genEncodedSecretKey(SALT_VALUE,"hex"); crypt.SetEncodedKey(hexKey,"hex");

the support email address has the complete source code so you should be able to easily track this bug down.

(Aug 08 '12 at 16:11) seasoned_geek

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..

link

answered Aug 08 '12 at 16:30

chilkat's gravatar image

chilkat ♦♦
11.8k316358421

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or __italic__
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Tags:

×64
×21
×1

Asked: Aug 07 '12 at 14:33

Seen: 2,411 times

Last updated: Aug 08 '12 at 16:30

powered by OSQA