I’m writing an implementation of the XXTEA encryption algorithm that works on ‘streams’, ie, can be used like: crypt mykey < myfile > output.
One of the requisites is that it doesn’t have access to the file at all (it only reads an fixed size block until find an EOF). The algorithm needs that the data bytes is multiple of 4, so its needed to add a padding.
For plain text a good solution is to pad with NULLs, and in the decryption just ignore the NULLs, but the same strategy cannot be used for binary streams (that can contain embedded NULLs).
I’ve read the common solutions, like padding with the number of missing chars (if it miss 3 chars, then append an 3, 3, 3 at the end) and etc, but I wonder: theres a more elegant solution?
Reading the question it looks like the security aspect of this is moot. Simply put, you have an api that expects a multiple of 4 bytes as input, which you dont always have.
Appending up to 3 bytes onto any binary stream is dangerous if you can’t make guarantees that the binary stream doesn’t care. Appending 0’s onto the end of an exe file doesnt matter as exe files have headers specifying the relevent sizes of all remaining bits. Appending 0’s onto the end of a pcx file would break it as pcx files have a header that starts a specific number of bytes from the end of the file.
So really you have no choice – there are no choice of magic padding bytes you can use that are guaranteed to never occur naturally at the end of a binary stream: You must always append at least one additional dword of information describing the padding bytes used.