Input text size

[pedroos]

Hi there!

(Obs.: the following is relative to v2.4.)

I noticed that the text length used for encoding seems to admit some extra information.

For example:

Input string: borbatonborbatozborbacaxborbafit Key: pwalsk Result: CC707A518AE12AB48DA543A8DEBE2A221ECD8B302B015B13255EBB9FFDBBA192A95AEE18A5D46C6A

This result seems to be produced when the final multiplied text length is 80. The text length is 80 because 1 is added to the original length 32 resulting in 33, which rounds up to 40 when searching for the next multiple of 8. That then is double to become 80.

If 1 was not added, then 32 being already a multiple of 8 would make the length of 32 * 2 = 64. In this case, the result is:

Result: CC707A518AE12AB48DA543A8DEBE2A221ECD8B302B015B13255EBB9FFDBBA192

This result ,when decoded and read back to 32 positions, already contains the original information: borbatonborbatozborbacaxborbafit. The extra information at the end of the string (which comes out as garbled text) seems to be the original extra 16 bytes (80 - 64). It could then be encoded more economically considering size 64 instead of 80, also avoiding including the extra information in the encoding.

It could also potentially increase decoding compatibility with other Blowfish implementations. For instance, when decoding this result in sladex, some extra garbled characters appear in the end.

Is there any specific reason for the +1 increase in the encoding buffer (PluginDefinition.cpp line 147)?

Thank you,

[chcg]

https://github.com/DominicTobias/SecurePad/blob/master/PluginDefinition.cpp#L147 and https://github.com/DominicTobias/SecurePad/blob/master/PluginDefinition.cpp#L214 need to be checked. Probably there for the null at the end of the character buffer used to transfer the input text from the editor. Probably it is not necessary for the encryption.

[pedroos]

I found something that may explain it. Quoting:

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.

If this is the case, then it could be a case of stripping off the padding bytes before encoding.