Block Filter: 1st byte missing

[Steve Butler]

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) <helpdesk at 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) <helpdesk at 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: sbutler at fchn.com<mailto:sbutler at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20150424/63d0fa0c/attachment.html>