That's an interesting question, not because I don't know the answer, but because I'm quite interested in knowing why you ask.
Don't need to tell me. I can imagine a few scenarios. For example, a whistle-blower that wants to sneak out documents without those documents being potentially matched based on file size.
Presently, it is possible to take an AES Crypt file and determine the precise size of the original file. Of course, one cannot determine the contents.
I have a laundry list of feature requests, and I could definitely see adding this to the list (if you are interested). However, to do this I would need to create a new version of the file format presently defined. There is no way to sneak in random octets into the current information flow.
If I were you and wanted an immediate solution to the problem, I would take the original file and put it in a .zip file. Then I would add random stuff to the zip file. And by "random", I mean files with random data in it to make the ZIP file less compressible. (If you were to add files containing nothing but zeros, for example, that would compress to an amazingly small file, which is not what you want.) I can definitely create some files with random data in it for you, if you're interested.
Once you have the ZIP file in hand, encrypt it. Rename it, too, so nobody would know it's a ZIP file.
In that way, you can vary the size of the file. The recipient would need to know it's a ZIP file so they can open it. Inside, there would be the file you intended to send along with several nonsense files (all of which could be clearly named so as to avoid confusion).
If I were to do this programatically, what I would do add a switch to aescrypt like this:
Code: Select all
aescrypt -e -p foo -x 25835 file.doc
The -x here could mean to pad the input stream with 25835 extra octets that get discarded when decrypting.
Like I said, it's an interesting feature. It might even have more utility than what I have in mind here. Alas, it's not there right now and it would have to be in a major upgrade to AES Crypt.
So for now, I'd suggest the ZIP file approach, stuffing random files into a ZIP file to mask the real file size. (You can even put a ZIP file inside a ZIP file.)