mdc error when decrypting GPG message

Question

I have a client and server system that regularly run scheduled tasks and communicate through xml files that have been encrypted by gpg. All required public keys have been successfully exchanged between the client and server. The encryption and decryption calls are being done from a batch file.

encrypt syntax

gpg.exe --batch --yes --recipient %1 --output %4 --passphrase %5 --local-user %2 --sign --encrypt %3

decrypt syntax

gpg.exe --batch --yes --output %3 --passphrase %4 --decrypt %2 2>%1

The client creates a xml file, encrypts it with gpg using server public key, signs with private key and uploads it to the server's ftp site. Server regularly checks for new files in ftp folder. For any new file it decrypts using gpg and then processes the xml inside the file.

For some of the xml files that the server tries to decrypt, I receive an error as follows:

gpg: block_filter 00AA8400: read error (size=7841,a->size=395)

gpg: mdc_packet with invalid encoding

gpg: decryption failed: invalid packet

gpg: block_filter: pending bytes!

The point to note is that this is not happening with all the files but with only some files. I haven't been able to find any commonality between the files that it fails on.

Is anyone familiar to what this error means? any suggestions to help track this down are welcome.

Answer 1

Finally figured it out. gpg was not the culprit here. when the server was checking for files in the specified folder, it was using the Append(fileHandler) method on Delphi to test if the file could be opened. But this method had a peculiar condition as if it found the ascii character 26 (i.e. CTRL+z) in the last 128 byte block of the file, it would remove everything from that character till the end of the file. This caused some part of the encrypted files to be deleted and subsequently caused the above error when decrypting it through gpg. After I replaced the Append method with Reset(fileHandler), encrypted files were no longer modified and decryption works perfectly.