2

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:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=TGyi
-----END PGP PRIVATE KEY BLOCK-----

In the new computer:

dutrV4c4hoPc6ntI3n9VztsL4LmmvoCcH969nJD6bTh4H1VMH98r8zECshtCSfVE
tMIIhXjA9xO1IZ6vMqHJU8TNhV2ttOE1Z/sUjcB46X4=
=/eDz
-----END PGP PRIVATE KEY BLOCK-----

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

Improve this question
  • 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. – dave_thompson_085 Aug 16 '18 at 4:16
  • Is it only the last four digits that differ? Nothing else at all? – forest Nov 15 '18 at 1:52
  • @forest yes, only the last four digits – nbari Nov 15 '18 at 4:12
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)

Improve this answer
  • both systems are macOS but keys are in yubico devices each – nbari Aug 15 '18 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. – Mike Ounsworth Aug 15 '18 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. – dave_thompson_085 Aug 16 '18 at 4:17
  • @dave_thompson_085 Thank you. I'm embarrassed I didn't find that. Re-working answer. – Mike Ounsworth Aug 16 '18 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.