Need help with padding

Question

I'm programming a file encryption software based on blowfish (which uses 64bit blocks). I will need a mechanism for padding, but I'm not sure how to implement that properly. All of the approaches I've seen so far could only be applied to text, where characters like 0x00 cannot contain data and thus can be used for special purposes. Since I'm planning on encrypting all file types I cannot rely on special characters which could be easily confused with real data.

Consider ANSI X.923 padding for example, how would the decryptor know that the sequence 00 00 00 04 is not some special data but padding?

I came up with two of my own solutions, but since I'm not a cryptoanalyst I don't know how strong they are...

1) The very first byte of the encrypted file will be the padding number (the number of actual data bytes in the last block). Yes, I'm giving it away and anyone with a hex editor will be able to see it. The last block is padded with random bytes. I feel like this is a big weakness since I'm not encrypting my padding number. Is this really a weakness and why?

2) The very first block of the encrypted file will contain the padding number and a bunch of random bytes. The decryptor will know exactly where to find the padding number (first byte of the first block). Once again, the last block is padded with random bytes. Is this a good approach?

3) Any other methods I can use?

Thanks in advance.

Answer 1

Consider ANSI X.923 padding for example, how would the decryptor know that the sequence 00 00 00 04 is not some special data but padding?

Because padding is always used. Thus if the file before padding was 41 42 43 44 00 00 00 04, it would be padded 41 42 43 44 00 00 00 04 00 00 00 00 00 00 00 08 then encrypted.

This rule, or similar ones differing on how the padding octets other than the last are generated, are common and fine when padding octet strings.

For the most general problem of padding arbitrary bit strings, one of the simplest and most general is bit padding, which appends a single 1 bit, then zero to b-1 0 bit(s) as necessary to reach a multiple of the blocksize $b$ (in bits). That can be designated as ISO/IEC 9797-1 padding method 1, but this standard does not prescribe un-padding. This should fail is there's not at least one block; removes final 0 bit(s) in the last block, and fail if that exhausts the last block; finally, remove the final 1 in that last block.

When restricted to octets in big-endian convention, bit padding becomes appending a 80 octet, then zero to b/8-1 00 octets as necessary to reach a multiple of the blocksize.

Use a simple padding rule, and always apply it; complexity and exceptions are the enemy of practical security. Whatever the method, beware of padding oracle attacks on decryption, and off-by-one coding errors in implementations.