Mailing List Archive

Encrypted GPG files
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 0xC1 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 .....
?



Best Regards,

Fredrik
Re: Encrypted GPG files [ In reply to ]
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


_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Encrypted GPG files [ In reply to ]
Hi!

Thanks for your analysis; I have one additional comment:

On Thu, 20 Feb 2020 23:28, Ángel said:

> 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).

gpg support IDEA so that is can't be the problem. A more likely problem
with older clients is that it does not support the MDC checksub we use
for nearly 20 years.

An easy test is to use the option --ignore-mdc-error for just this one
message and if that works, asking the communication partner to update
their software to something from the millenium.


Salam-Shalom,

Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.