How come the same GPG key can have two different ASCII-armor?

Question

I'm trying to set up a gpg key generator/manager web based using openpgpjs and an openpgp server. I'm able to generate the key pair with no trouble at all, but when I want to send the armored public key to the pks, I get an error: "Error decoding keyblock".

After several tries (with url encoding, with no url encoding, through Ajax request or with a copy/paste directly on the pks' form...), I decided to try and import it in GnuPG : it worked!

Then I tried to export the key from GnuPG and copy the result in the pks's form, it worked too. So I tried to compare the imported file and the exported one expecting that some CR+LF would be differents. I was surprised that the entire ASCII-armored key is different.

So I have two questions:

• how is it possible for the same key to have two different ASCII-armor?
• how can I have my Javascript issue an armored key that will be accepted by the pks?

Answer 1

As stated by @owlstead, the two applications are using different version of the open PGP protocol. Openpgpjs provides ASCII armored key using the new format while pks only accept the old format.

You need to decode the first byte of the key to notice it: Take the first 2 letters of the key and use the radix-64 table to get the binary value, then check the first 8 bits (one byte).

The first bit is always one, the second one should be one too (it means it's a new packet), then the following is the binary value corresponding to the content of the ASCII armor :

• 0 -- Reserved - a packet tag must not have this value
• 1 -- Public-Key Encrypted Session Key Packet
• 2 -- Signature Packet
• 3 -- Symmetric-Key Encrypted Session Key Packet
• 4 -- One-Pass Signature Packet
• 5 -- Secret Key Packet
• 6 -- Public Key Packet
• 7 -- Secret Subkey Packet
• 8 -- Compressed Data Packet
• 9 -- Symmetrically Encrypted Data Packet
• 10 -- Marker Packet
• 11 -- Literal Data Packet
• 12 -- Trust Packet
• 13 -- User ID Packet
• 14 -- Public Subkey Packet

In the old format, the binary value is coded on 4 bits (bits 5 to 2), in the new one, it's on 6 bits (from 5 to 0).

More details can be found in RFC 2440, chapter 4.

Answer 2

Some of the PGP packets could be exchanged, e.g., if you have more than one non-primary UIDs, or more than one subkeys. Next, there is a new packet format, that causes a different ASCII armor too. And last but not least the signature packets contain the left two bytes of the hash value, which are no more checked. If you change them, you will hardly detect the change when looking at it, but the CRC24 sum at the end will change.