login about faq


As part of my Chilkat evaluation, I wanted to confirm that I could successfully decrypt a Blowfish ECB message emitted as part of the IHO S-63 standard. The standard says it uses Blowfish in ECB mode, with RFC1423 padding. When I try to decrypt under these settings in ChilKat, decryption claims to succeed, but the output buffer has zero size.

Here's the code I've written:

CkByteData secretKey;
secretKey.append2(identity.hwId, _countof(identity.hwId));  // "12345"
crypt.put_KeyLength(_countof(identity.hwId) * 8);

    CkByteData input, output;
    input.append2(cellKey1_encrypted, _countof(cellKey1_encrypted));    // 8 bytes of data
    if (input.getSize() % 8 != 0)
        input.pad(8, 0);   // pad as RFC1432
    if (!crypt.DecryptBytes(input, output))   // THIS SUCCEEDS
        CkString text;
        const char* pszError = text.getAnsi();
        return false;
    if (!output.getSize())   // FAILS because output.getSize() == 0
        CkString text;
        const char* pszError = text.getAnsi();
        // pszError says decrypt succeeded, so why is the output buffer empty?
        return false;

As an experiment, I encrypted AND decrypted with these settings on a test message, and the buffers were properly sized in the end. I'm guessing I'm not decrypting symmetrically with the S-63 data, but if so, I would've expected garbled data rather than an empty output buffer.

Please advise, I'm ready to purchase licenses once I get past this.



This question is marked "community wiki".

asked Feb 18 '13 at 00:35

BarryA's gravatar image


Make sure you test with data that is longer than a single block. For example, the Blowfish algorithm has a block size of 8 bytes. Make sure your encrypted data is more than 8 bytes. If your secret key is incorrect, then you'll decrypt to garbled data, and it may be that the result of the garbled data indicates padding such that ALL of the result is padding, and it is all removed, and you get 0 bytes back. Therefore, if you test with a larger amount of data, then an incorrect key will result in garbled data being returned, with potentially only the last block being missing.

Also, check the contents of the LastErrorText for more information.


answered Feb 18 '13 at 08:36

chilkat's gravatar image

chilkat ♦♦

The encrypted data that is passed to me is 8 bytes in length, with only 5 bytes being relevant and the rest is padding.

Per the code snippet, LastErrorText() reports DecryptBytes() succeeded.

The hint about unpadding was helpful. For decryption only, I call set_Padding(2 = random) to discourage/disable any unpadding behavior afterward. This seems to fix the problem, as I now get 8 bytes of output, which I will only extract the first 5 bytes.




answered Feb 18 '13 at 23:34

BarryA's gravatar image


Your answer
toggle preview

Follow this question

By Email:

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



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



Asked: Feb 18 '13 at 00:35

Seen: 2,181 times

Last updated: Feb 18 '13 at 23:34

powered by OSQA