Home/ Questions/Q 1099157
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T00:41:26+00:00

I’m running Windows Server 2k8 (maybe that’s half the problem?) Anyway, I’m getting different

  • 0

I’m running Windows Server 2k8 (maybe that’s half the problem?) Anyway, I’m getting different values out of different Blowfish modules in various languages. Is there one which can be relied upon as the standard?

For the following examples, assume the key is password and the plaintext 12345678.

a. The Online Encrypt Tool with Algorithm set to Blowfish mode ECB and Base64 Encode the output checked gives 2mADZkZR0VM=. I’ve been using this a my reference point, wise or otherwise.

b. The following Perl code uses Crypt::ECB and MIME::Base64

use MIME::Base64;
use Crypt::ECB;
$crypt = Crypt::ECB->new;
$crypt->padding(PADDING_NONE);
$crypt->cipher('Blowfish') || die $crypt->errstring;
$crypt->key('password'); 
$enc = $crypt->encrypt("12345678");
print encode_base64($enc);

This outputs 2mADZkZR0VM= with PADDING_NONE (which compares well with ‘a.’ above). However, when padding is set to PADDING_AUTO it outputs 2mADZkZR0VOZ5o+S6D3OZw== which is, in my mind at least, a bug as the plaintext is 8 characters long and in no need of padding.

c. If I use Crypt::Blowfish as below

#! c:\perl\bin 
use Crypt::Blowfish;
use MIME::Base64;

my $key;
my $plaintext;

$key = "password";
$plaintext = "12345678";

my $cipher = new Crypt::Blowfish $key; 
my $ciphertext = $cipher->encrypt($plaintext);
my $encoded = encode_base64( $ciphertext );
print $encoded;

then I get 2mADZkZR0VM= which matches ‘a.’ above. Trouble with this module though is that one has to segment things into 8 byte chunks for encoding; it has no chunker of its own.

d. If I use the source at http://linux.die.net/man/3/bf_ecb_encrypt (which I did for a recent PHP ext project) then I get the same answer as ‘a.’. I’m inclined to trust this code the most as it’s in use in SSLeay and OpenSSL.

e. The BlowfishEx.EXE in DI Management’s Blowfish: a Visual Basic version with PKCS#5 padding gives 2mADZkZR0VOZ5o+S6D3OZw== which is the same as the Crypt::ECB results with PADDING_AUTO. With Padding set to None I get 2mADZkZR0VM= which matches ‘a.’

I’ve partly answered my own question writing this: looks like I just have to modify DI Management’s code for the VB6 project. And maybe suggest the same to the writer of Crypt::ECB.

But the question remains: is there a trustworthy blowfish reference platform?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your problem doesn’t seem to be with whether they implement the Blowfish algorithm correctly. In the “no padding” variant, they all seem to produce identical results.

    That leaves a question of whether an 8-byte input should be padded at all. The answer to this is pretty simple: PKCS #7 requires that there is always at least one byte of padding added to the input. The reason for this is simple: on the receiving end, there needs to be an unambiguous way to remove the padding. In the case of PKCS#7, the value of the padding bytes is always the number of bytes of padding that needs to be stripped off by the recipient.

    So, when you receive material that’s been padded with PKCS7, you decrypt the block, then look at the last byte in the decrypted output, and remove that many bytes from the block. Without a block of padding on the end, the receiver would normally look at the last byte of actual data, and whatever value that byte happened to contain, strip off that many bytes (though it should probably tell you there’s a problem if the number is larger than 8). In any case, to assure correct operation, there must always be at least one byte of padding. In your case, that means the input gets expanded out to 16 bytes instead of 8.

    • 0