4
$\begingroup$

I am currently experimenting with the Blowfish encryption.

I noticed that the decrypted message and the original message doesn't have the same length. This applies for the ECB, CBC and CTR mode.

enter image description here

The difference of bytes from the original message to the decrypted message are just trailing zeros at the end of the array. However, the zero-padding-length at the end seems to vary.

Is there :

  1. A way to produce a decrypted output with the same size as the input message?
  2. A way to calculate the length of zero-padding at the end (so that I can cut them off in the end)
$\endgroup$
  • 2
    $\begingroup$ Not with ECB mode. 16 bytes is your 128 bit block. You could use CFB mode if you need to split the block, but be aware this effectively turns your block cipher into a stream cipher (so you gain new security risks like being able to flip a chosen bit) $\endgroup$ – MickLH Feb 27 '17 at 3:21
  • $\begingroup$ I just realized that Blowfish works with blocks of 8 bytes, so if messagelength % 8 == 0 then the decrypted output has the same length as well, otherwise padding as added to match the condition mentioned. $\endgroup$ – yq8 Feb 27 '17 at 4:42
3
$\begingroup$

Is there a way to produce a decrypted output with the same size as the input message?

Yes, CTR mode should work for that. You must have a broken implementation as there is no padding required for CTR mode. You could simply use the leftmost bytes of the ciphertext though. If decryption fails because of that then you could simply pad the ciphertext with zero's, decrypt, and remove the number of (now random) padded bytes so your plaintext length matches the ciphertext length.

Note that often an IV is send as well. The IV needs to be unique for CTR mode (in such a way that the counter is always unique). This is even more troublesome for 8 byte block ciphers such as Blowfish than for 16 byte block ciphers such as AES. You would need to use a counter IV or establish the IV otherwise to make the ciphertext the same length as the plaintext.

A way to calculate the length of zero-padding at the end (so that I can cut them off in the end).

For plaintext ASCII text you can simply remove all zero bytes at the end; zero is a control character called NUL which should not appear in printable text.

Note that there are two forms of zero-padding: one that always pads and one that doesn't always pad (which is more often used). You could encrypt a 8 byte block of plaintext to see which one you got.

Note that for binary messages that may contain a zero byte at the end that zero-padding is not deterministic, meaning that you cannot determine the exact amount of padding. You would need to implement a padding mode such as PKCS#5/PKCS#7 padding yourself if you require that.


Do not use Blowfish, use a 16 byte block cipher, preferably AES in an authenticated mode such as GCM (which does add the authentication tag as overhead though). Even Bruce Schneier - the inventor - doesn't recommend Blowfish anymore.

An 8 byte block cipher is especially harmful for CTR mode. You'd better use CFB or OFB mode if you have to stick to Blowfish. Those are also modes that turn the block cipher into a stream cipher, so they do not require padding.

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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