Archived Forum Post

Index of archived forum posts

Question:

Blowfish ECB decryption to binary succeeds but returns zero-length output buffer?

Feb 18 '13 at 23:34

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

---

Answer

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.

---

Answer

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