Invalid packet error message
bd9439 at att.com
Tue Jan 8 16:10:25 CET 2013
Thanks for the excellent explanation!
Before I ask for the file to be retransmitted, one quick question (perhaps obvious but bear with me):
If I ask the sender to use the -a option, the resulting file will be ASCII and as such, I would download it as "text" from our FTP server, not "binary", correct?
It just occurred to me that the problem was on the sender's side; perhaps they uploaded the file as "text" when they placed it on our FTP server (we use an intermediary FTP site). At any rate, I think I understand now.
Thanks very much!
From: Werner Koch [mailto:wk at gnupg.org]
Sent: Tuesday, January 08, 2013 12:18 AM
To: DUELL, BOB
Cc: gnupg-users at gnupg.org
Subject: Re: Invalid packet error message
On Mon, 7 Jan 2013 22:14, bd9439 at att.com said:
> gpg: [don't know]: invalid packet (ctb=70)
> Does anyone know what this means? I tried several Google searches but
Your input data is corrupted. OpenPGP messages are constructed from
several packets, each packets starts with a tag byte commonly called CTB
indicating the type of the packet and how the length of the packet is
specified. 0x70 is not a valid CTB, thus you see this message.
A common cause for a corrupted message is the use of a non binary clean
channel (e.g. using ftp without switching to binary mode). Mail
software may also corrupt the message. Ask the sender of the message to
encapsulate it in a ZIP or tar file and than unzip it before decrypting.
If this works or you can't unzip it your transport channel is non 8 bit
clean. A quick work around would be the use of the --armor or -a
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
More information about the Gnupg-users