bc-java icon indicating copy to clipboard operation
bc-java copied to clipboard

OpenPGP: Old vs. New Packet Format

Open vanitasvitae opened this issue 4 years ago • 3 comments

Hey everyone!

I noticed, that BC supports both the old1 and new2 packet length format for OpenPGP packets.

When being serialized, BC's packets basically decide which format to use via a boolean flag passed into writePacket() of the BCPGOutputStream3.

This flag is hard coded in every packet class and there is no clear pattern to when the new format is used and when the old.

My question is: Would it be possible for a future BC release to exclusively use the new format when producing packets? I guess support for the new format should be available in pretty much any other active OpenPGP implementation. In the end, there are packets in BC which already use the new format, so any implementation that needs to interop with BC likely already supports parsing the new format.

Here is a related discussion in PGPainless' issue tracker4.

What do you say?

Happy Hacking, Paul

vanitasvitae avatar Aug 14 '21 11:08 vanitasvitae

Are there any updates on this? Would you accept a PR that changes all PGP packets to use the new format? I see that this would cause quite a bunch of encoding tests to break, which would need to be rewritten / updated.

The upcoming revision of rfc4880 will make emitting the new packet format a MUST, so its time to make the switch.

vanitasvitae avatar Feb 12 '22 22:02 vanitasvitae

I see that in some places it is possible to convince BC to make use of the new packet format, e.g. when encoding key rings (by using keyRing.encode(myBcpgOutputStream) where myBcpgOutputStream was instantiated with newFormatOnly = true.

However, this approach falls short when dealing with encrypted / compressed / literal data. For example here PGPEncryptedDataGenerator.open(outputStream) will wrap the given output stream into a BCPGOutputStream instance that makes use of the old format, no matter how the outputStream instance that was passed in was configured.

vanitasvitae avatar Feb 12 '22 23:02 vanitasvitae

As an inspiration on how to design an upgrade path: In order to ensure intact round-trip encoding, Sequoia-PGP does remember the CTB type when reading packets and uses that when re-encoding. That way test vectors stay intact, while the new format can be emitted when the read packet was using it already previously.

vanitasvitae avatar Feb 21 '22 14:02 vanitasvitae