I use the OpenSSL library for Blowfish encryption in ecb mode. The message are encrypted, but with the wrong padding, because of it I have a problems with decryption. What am I doing wrong?

I checked with:


and java.

It should be:

I get it:

#include <iostream>
#include <string>
#include "Base64.h"
#include <openssl/blowfish.h>

int main()
    // blowfish key
    const char *key = "topsecret";
    const unsigned char* in = (const unsigned char*)"hello world how are you today";

    BF_KEY bfKey;
    BF_set_key(&bfKey, strlen(key), (const unsigned char*)key);

    size_t InSize = strlen((char*)in) + 1;
    size_t OutSize = ((InSize + 7) / 8) * 8;

    unsigned char *out = (unsigned char *)malloc(OutSize);
    unsigned char *outnext = out;

    while (InSize >= 8) {
        BF_ecb_encrypt(in, outnext, &bfKey, BF_ENCRYPT);
        in += 8;
        outnext += 8;
        InSize -= 8;
    if (InSize > 0) {  // Cope with non-octal length
        unsigned char buf8[8];
        memcpy(buf8, in, InSize);
        for (int i = InSize; i < 8; i++) {
            buf8[i] = ((int)'0');
        BF_ecb_encrypt(buf8, outnext, &bfKey, BF_ENCRYPT);

    std::cout << Base64::base64_encode(out, strlen((char *)out)) << std::endl;


    return 0;



  • $\begingroup$ 1) Do you need to match that specific library? What you're doing is about as secure as ROT13. 2) Keys are sequences of bytes, not strings. 3) There are many different paddings, zero padding is not a good choice since it truncates the plaintext if it contains the padding character. 4) You're padding with the '0' digit, not with the ASCII code 0. $\endgroup$ – CodesInChaos Sep 28 '16 at 12:07

I use the OpenSSL library for Blowfish encryption in ecb mode. [...] What am I doing wrong?

You're using ECB mode and no authentication.

But as for the question itself.

Your input length is 29+1 bytes, which should get padded to 32 bytes, which should be ceil(32/3*4) = ceil(42.67) = 43 characters when base64-encoded, plus one = to round up to four. The output from the site you linked to seems to be of that length, but the output from your code looks like 48 characters, or 36 bytes. Extra bytes appear to show up from somewhere.

The output is made using this call to base64_encode:

unsigned char *out = (unsigned char *)malloc(OutSize);
base64_encode(out, strlen((char *)out))

The length is determined with strlen. But is the data in the out buffer terminated with a zero byte? I don't see that terminator anywhere, so it may be that strlen and hence base64_encode read past the buffer. Check what the strlen output is, compared to OutSize.

In any case, the output from the cipher might contain zero bytes too, so I don't think you should be using strlen here at all.

Also, the padding you are using destroys the length of the plaintext. That is, foobar and foobar0 pad to the same string, foobar00 and there's no way to tell them apart. You may want to consider some other method of padding. (Basically, encode the length of the padding in the padding itself, which means you may need to pad a full block.)


Not the answer you're looking for? Browse other questions tagged or ask your own question.