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
