Error: Input file is too short.

[arthurz]

Hello,

I have successfully encrypted a XML file using the command line utility.
However, on an attempt to decrypt the file I am getting Error: Input file is too short.
Worst of all: the file got deleted completely!

The following command line was used to encrypt:

C:\Software\AESCrypt\AESCrypt308a_win32_console>aescrypt.exe -e -p test -o "C:\U
sers\Dummy\Documents\Visual Studio 2008\Projects\SSIS_SandBox\SSIS_SandBox
\SandBoxPackage.dtsConfig" "C:\Users\Dummy\Documents\Visual Studio 2008\Pr
ojects\SSIS_SandBox\SSIS_SandBox\SandBoxPackage.dtsConfig"

Is there any way to decrypt the file? Also good to know why it is erroring and wiping the file out.

[paulej]

If the error message says that the input file is too short, then it means that the file is too short to be a valid AES Crypt file. Other file checks cannot be performed due to the short length of the file.

The reason you are getting this error is that you are specifying the input and output file to be the same file. What's happening is that it begins to write the output file and then starts reading the input file. Upon getting the error, AES Crypt cleans up by removing the partially-complete output file. Unfortunately, that's the input file in your case. Either way, though, the input file would have been garbled as AES Crypt started writing.

AES Crypt could try to check that the input and output files are the same. However, this is not generally done on command-line apps. For example, "tar -czvf text.txt text.txt" will exhibit the same sort of problem. If one does not specify a default output file, AES Crypt uses the same as the input file, but appends .aes to the end. So, it will be "SandBoxPackage.dtsConfig.aes" in your case. You do not need to specify the output file unless you want it written to a different location or have a different name than what is used by default.

[arthurz]

Thank you for the prompt reply, I must admit I suspected this being the case (just could not believe the encryption app is so flawed, I realized it was me), but I find this situation being not ideal.
Examples: when I deal with software that expects a file to have a certain name ever (e.g. when a metadata is attached/provided) this requirement breaks the validity.
I hoped the encryption would spawn a temp copy somewhere in say %tmp% dir for the sake of encryption.

[paulej]

AES Crypt does not require input or output files to have a given name. You are free to name them whatever you want. Just to have a default, we used .aes as the extension for encrypted files. We could place files in a temporary directory, but what would be the advantage? And what do we do if we encounter errors during the move process? On any machine where there are multiple users, we would not want decrypted data in a place where other users could possibly view it. (File permissions could control that, but I would rather not even draw attention to it.) One of the big reasons I prefer not using a temp directory is that it would then take time to move files across file systems on certain operating systems. The files I encrypt are usually gigabytes in size.