I created a backup of a gpg key by doing:

gpg -a --export-secret-keys foo@bar > private.key
gpg -a --export foo@bar > public.key

Then on another system, I import them:

gpg --import private.key
gpg --import public.key

I trusted the key as ultimate, and the backup seems to be working, the only thing that I notice is that when doing:

gpg --armor --export-secret-key foo@bar

The last 4 characters differ for example:


In the new computer:


Wondering why the last characters differ, in this case =TGyi and =/eDz

  • There must be some difference in the data; check all of it. Or do --list-packets on each and compare the outputs, although the difference can be in parts of some packets that list-packets doesn't or can't display. Aug 16, 2018 at 4:16
  • Is it only the last four digits that differ? Nothing else at all?
    – forest
    Nov 15, 2018 at 1:52
  • @forest yes, only the last four digits
    – nbari
    Nov 15, 2018 at 4:12

1 Answer 1


TO THE ASCII ARMOR SPEC! -- RFC 4880. The ASCII ARMOR specification is given in Section 6.2:

Concatenating the following data creates ASCII Armor:

  • An Armor Header Line, appropriate for the type of data
  • Armor Headers
  • A blank (zero-length, or containing only whitespace) line
  • The ASCII-Armored data
  • An Armor Checksum
  • The Armor Tail, which depends on the Armor Header Line

So the last 5 characters (=TGyi and =/eDz) are a checksum of the armored data. Oddly Section 6.2 doesn't define the checksum format, but an older version of the spec, the 1995 Internet Draft for PGP, does:

The Armor Checksum is a 24-bit CRC converted to four bytes of radix-64 encoding, prepending an equal-sign (=) to the four-byte code.

Checksums are used in a number of other places is the RFC, always defined as two-octet sums modulo 65536:

Then a two-octet checksum is appended, which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536.

It does seem a bit odd that two copies of the same data would have different checksums, ... maybe there's enough ambiguity in the spec that different versions of openpgp use different methods to compute the checksum?

(Disclaimer: this is my first time diving into the PGP spec, perhaps someone more familiar with it can explain properly)

  • both systems are macOS but keys are in yubico devices each
    – nbari
    Aug 15, 2018 at 21:23
  • The yubikey manager tells you which version of openpgp it's using. If my theory is right, then it will need someone familiar with the openpgp source code to tell us exactly how the checksum is computed, and if this has ever change across different versions. Aug 15, 2018 at 21:32
  • rfc1991 in Aug 1996 (albeit classified informational), replaced by 2440 Nov 1998 standards-track which moved these items to 6 without material change other than adding PRIVATE KEY BLOCK and detached SIGNATURE as types, and then by 4880 Nov 2007. Aug 16, 2018 at 4:17
  • @dave_thompson_085 Thank you. I'm embarrassed I didn't find that. Re-working answer. Aug 16, 2018 at 13:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .