GPG Version: Kleopatra Ver 2.1.1
PGP Version: PGP Command Line 10.2 build 283
1) Client perform encryption using GPG4Win. File size is 30kb. File output is abcd.dat.gpg
2) Client upload the encrypted file abcd.dat.gpg to our FTP server via SFTP Protocol (Tectia Client). The transfer method is ASCII mode.
3) We obtain the encrypted file abcd.dat.gpg from FTP server to PGP server via SFTP Protocol (Tectia Client).
4) We rename the encrypted file abcd.dat.gpg to abcd.dat.pgp
5) We perform the decryption usng the command: pgp --decrypt "filename"
Error occured: 3090:operation failed, bad packet
File did not decrypted.
We tried the command pgp --decrypt "filename" --temp-cleanup off. We manage to retain the temporary output file. But the content of the file is not complete.
I need help with the root cause and what is alternative solution for this.
Any GURU can help please? Thanks ~
This Knowledge Base Article may help:
Hi Tom,thanks for the redirect, but i believe i have tried this solution and it doesn't work in our current process flow.
We have tried to decrypt by perserving the temp file. But the problem is the temp file's content is not complete. (We expecting the content of the file to end with a line = T 112233445566779988). The content of the file is rather critical for the operation.
You might want to try the current Trialware to confirm that the current version takes care of this:
It's possible that there is in fact a problem with the file (a bad packet). If you run "pgp --dump-packets" on the file, does it report any issues? Also, if you try transferring the file in binary mode, does that help?
Hi dfinkelstein, attached is the result.
I was wondering will the file transfer method of SFTP caused the error as well. The client upload file on daily basics (Mon - Fri), and we hit the error for once or twice per week.
The transfer method was force to run under ASCII mode:
If you look at the file, does it appear to be ascii armored?
Can you try to do the transfer in binary mode? Note that a .pgp or .gpg file may be binary if it is has not been ascii armored.
Hi, client did not encrypt the file in ascii armored mode.
May i know how would a file more (ascii/binary) contribute to this bad packet error?
*Client upload another file just now, file seems ok, able to decrpyt without error.
If a pgp file is not ascii armored, then it will contain data that is considered "binary" -- all bits of the data bytes may be used. Data that is "ASCII" compliant will never have the highest bit set, as ascii values fall below 128.
When "binary" data is transferred in "ascii" mode, the data will not transfer over properly, since these highest bits will not be faithfully transferred over.
We been hit by the same error again today.
I've just advise the client to perform the file transfer using binary format.
We will keep monitor it for the rest of the week to confirm the possible solution/cause.
You (and your client) may want to adjust your set of ASCII extensions, to remove pgp and gpg from the list. Those may be (and often are) binary.
We being hit by the same error again today even though the client claim they had set the transfer mode to binary and ASCII extension in Tectia Client is set to include TXT, HTML & HTM only.
If "pgp --dump-packets" is still showing a bad packet, then either there is a problem on the encoding side (which is doubtful) or there is still a problem somewhere in transport. (Possibly there is some issue in PGP Command Line but for files that small there is no known interoperability issue with that version of PGP Command Line and GnuPG.) One thing you could do is have your partner take a checksum of the file right after it is created (and before it is copied or uploaded anywhere), then you do the same thing after you download it.
How can i do that, the checksum of files? And what kind of output i'm anticipating?
You are looking to calculate a hash value of the file after it is encrypted, and again after you receive it. May programs can do this ("openssl md5", "md5"). On Windows, there is also a command line utility that can do it, see http://support.microsoft.com/kb/841290/en-us
You run the program giving your file as input. It will output a string of characters. You want to compare the character string on both sides to make sure they are the same. If not, the file has been altered in transit somehow.
I've arranged with our client to prepare the result of the checksum on the next file transfer. Will updated again once we have the result.
Thanks for the advise. Do stay tune ~
Today we have 2 client with the report bad packet file issue again.
We had captured the checksum of the file before being upload/download using Tectia Client, the result are as attached:
It is obvious that the file is changed after the upload.
Can we conclude that the culprit is due to Tectia Client?
Yes, this is absolutely a problem with the upload process or software. If I were to guess, it is not properly respecting that the file should be binary.
One workaround you could try is for your partner to ascii armor their output by also using the "-a" option. You don't need to make any changes on your side to deal with ascii armored input.