Encrypted GPG files

[Ángel]

On 2020-02-20 at 12:53 +0000, fredrik.a.lindstrom--- via Gnupg-users
wrote:
> Hi all,
>  
> We receive PGP encrypted files from several external parties that uses
> many different tools to create PGP files and I have noticed a
> difference between these files that cumbers me.
>  
> We never (well almost never) have issues with binary GPG files that
> starts with 0x85 0x01 ..... as the first 2 bytes in the binary file.
> Now I have received binary PGP files that starts with 
>  0xC0 ..... and have not been able to smoothly to decrypt these files.
>  
> Every time I encrypt files then the binary output file always starts
> with 0x85 0x01 ..... and I am using version 2.2.9.
>  
> How can I create PGP encrypted binary files that starts with 0xC1
> 0xC0 ..... ?

See https://tools.ietf.org/html/rfc4880#section-4.2

The files starting with 0xCx are using the "new packet" format

A file starting with 0x85 0x01 mean:
0x80 → The bit 7 is always set
	Bit 6 is not set, ergo it's in old format:
		- The packet tag is 1 (5 >> 2): Public-Key Encrypted Session Key Packet
		- The length is 1 (5 & 3): two-octet length (0x01 ...)


A file starting with 0xC1 0xC0 would mean
0xC1 → The bit 7 is always set
	Bit 6 is set, ergo it's in new format:
		Packet tag is 1 (0xC1 & 3F): Public-Key Encrypted Session Key Packet

The length is provided by the next bytes, 0xC0 would be the start of a
two-byte length header (from 192 to 8383
bytes)


If you are not able to decode new format files, maybe it's a problem
with your client? What do you mean by smoothly decoding them?
Are you able to successfully  decode them from the command line?

I suspect that the problem may not actually be the packet format, but
something else presented by the same client that is choosing new format
(e.g. it could be choosing IDEA as cipher).

Issuing a  gpg --list-packets  over the file will probably give you
valuable information.


Kind regards