Question

I'm using PHP to write an application where the user can encrypt his text several times with several possible algorithms to use. At first i thought this was really simple, but then i thought of the problem that occurs, when data is padded to blocksize, encrypted and then decrypted.

At first i thought i could just remove the null-bytes after every decryption process to get the original data before padding. Now if the data has several null-bytes at the end itself, then removing the null-bytes after the decryption process will just remove parts of the original data and end in losing data and maybe wrong decryption too (the last point depends on the blocksize of the following decryption algorithms). Although the possibility that the data or data after several encryption processes contains several null-bytes is nearly zero, I am looking for a solution to solve the problem described above.

If I dont want to strip null-bytes from the data, I will also get some annoying results depending on the blocksizes of used algorithms. To show that i wrote a python programm, which has three cryptographic algorithms, one operates with a blocksize of 2 bytes, another operates on a blocksize of 3 and the last one has a blocksize of 4, so you can compare them to 128-, 192- and 256-bit algorithms. I started with some random bytes and encrypted them several times, then decrypted them without removing null-bytes after every decryption-process. The programm printed the bytes after every decryption/encryption-process in hexadecimal format, here is the output with some comments from me:

48 61 6c 6c 6f                      //thats our data at the start
da b4 28 fe 9e 4a                   //now the 3-byte algorithm was run -> padded to 6 bytes
5e 62 04 72 1a d8 d2 a4             //used the 4-byte algorithm -> padded to 8 bytes
cc a1 43 e0 f5 e7 40 eb 81          //3-byte algorithm used again -> padded to 9 bytes
48 61 7a 07 71 1e 3f 0f 05 8d 98 a4 //at last used the 4-byte algorithm -> padded to 12 bytes
cc a1 43 e0 f5 e7 40 eb 81 00 00 00 //first encryption done, notice the three null-bytes and the similarity to line 4
5e 62 04 72 1a d8 d2 a4 00 92 0f 2a //secound encryption done, not removed null-bytes "decrypted", but the rest goes well, as seen in line 3
da b4 28 fe 9e 4a 00 00 84 1a 8d 03 //third encryption done, same as above, decryption of null-bytes results in chaos, but original data still the same
48 61 6c 6c 6f 00 92 0f ae 88 98 be //last encryption, we got original data with some near random bytes

You can see that the first decryption-process goes well, the secound one too, except for the 3 padding-bytes that get "decrypted". So, after each encryption process, we come closer to our original data, but we keep decryption these padding bytes. (Note: If someone doubts my encryption/decryption-functions, I tested them several 100 times and they worked every time, I can also post the source code if required or doubted)

To put all this to a simple question, when I decrypt data, how can I know, which null-bytes are part of the original data and which are added by the encryption algorithm? Do you have any ideas how I can do that?

Was it helpful?

Solution

Instead of zero-padding your data, you can use a padding mode such as PKCS#7 which encodes the amount of padding in the padding bytes themselves. This allows the number of padding bytes to be determined when decrypting so that they can be removed leaving only the original plaintext.

Essentially, the padding bytes are all = the number of bytes of padding added. E.g. if 3 padding bytes are required, then the padding would be 3 bytes of 0x03.

There is always at least one byte of padding, that means that if the plaintext is already a multiple of the blocksize, then an additional block consisting only of padding must be added. This ensures that it's possible to distinguish between a plaintext that's an exact multiple of the block size and which already ends with n bytes of n, and a plaintext that has been padded with n bytes.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top