Client with PGP is encrypting files that we can usually decrypt with GnuPG
1.4.16 on an Oracle Enterprise Linux (2.6.8-274.17.1.0.1.e15).
Occasionally gpg reports: gpg: block_filter: 1st length byte missing.
Client will re-encrypt and resend. That file always (even with different name)
is not decrypted with above message.
Do a: gpg --no-batch --verbose --verbose --list-packets [filename]
:marker packet: PGP
:pubkey enc packet: version 3, algo 16, keyid 6BA0BA0A5A2CEA48
data: [2047 bits]
data: [2048 bits]
gpg: public key is 5A2CEA48
gpg: using subkey 5A2CEA48 instead of primary key 1B32D54B
You need a passphrase to unlock the secret key for
user: "First Choice Health Network (FCHN) <helpd...@fchn.com>"
gpg: using subkey 5A2CEA48 instead of primary key 1B32D54B
2048-bit ELG-E key, ID 5A2CEA48, created 2001-10-16 (main key ID 1B32D54B)
gpg: public key encrypted data: good DEK
:encrypted data packet:
length: unknown
gpg: encrypted with 2048-bit ELG-E key, ID 5A2CEA48, created 2001-10-16
"First Choice Health Network (FCHN) <helpd...@fchn.com>"
gpg: CAST5 encrypted data
gpg: block_filter: 1st length byte missing
:compressed packet: algo=1
gpg: decryption okay
gpg: WARNING: message was not integrity protected
But gpg exits with status 2.
The 'gpg: decryption okay' message is not seen unless the 2nd -verbose is
listed on the command line. Not conducive to automated processing.
Manual inspection of the file with xxd shows it starts with: 0000000:
a803 5047 50c1 c14e 03 [my pk sub key id] etc.
I believe that third packet starts at hex location 217 in this line: 0000210:
3e65 83a0 73a7 c9ec xxxxxx I believe the c9ec means tag 9 with 4096 packet
length.
That should take us to locatin 1219 in this line:
0001210: 34ed 52dd 5afb 457a 0c06 xxxx I think 0c is the next packet length of
12 of which the 06 is the first byte.
The file ends on the next line:
0001220: 0edb ef22 ac
This all looks good to me. Is gpg expecting another packet? Or another length
byte?
--Steve
PS I've been using GnuPG for well over a decade and have run into this problem
on occasion. Always a re-encrypt has solved it. With this client that is no
longer the case.
Stephen M. Butler, PMP, PSM
IT Manager - Software Engineering
First Choice Health Network
Email: sbut...@fchn.com<mailto:sbut...@fchn.com>
Voice: 206-268-2309
Fax: 206-268-6173
--
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential
and privileged information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply e-mail and destroy all copies of the original
message.
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
