login about faq

Hello,

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:

crypt.put_CryptAlgorithm("blowfish2");
crypt.put_CipherMode("ecb");
CkByteData secretKey;
secretKey.append2(identity.hwId, _countof(identity.hwId));  // "12345"
crypt.put_SecretKey(secretKey);
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;
        crypt.LastErrorText(text);
        const char* pszError = text.getAnsi();
        return false;
    }
    if (!output.getSize())   // FAILS because output.getSize() == 0
    {
        CkString text;
        crypt.LastErrorText(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.

Thanks!

Barry

This question is marked "community wiki".

asked Feb 18 '13 at 00:35

BarryA's gravatar image

BarryA
1334


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.

link

answered Feb 18 '13 at 08:36

chilkat's gravatar image

chilkat ♦♦
11.8k316358421

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.

Thanks,

Barry

link

answered Feb 18 '13 at 23:34

BarryA's gravatar image

BarryA
1334

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:

×2
×2

Asked: Feb 18 '13 at 00:35

Seen: 1,154 times

Last updated: Feb 18 '13 at 23:34

powered by OSQA