1

gpg version: 2.2.16 (as part of Gpg4win 3.1.9).

Is this supposed to happen: Every export of my private key partially differs from every other export as follows: 2 middle chunks of the main block, and the last 4 characters before the footer. So it looks like this:

-----BEGIN PGP PRIVATE KEY BLOCK-----
< blank line >
< identical chunk of characters >
< non-identical chunk 1 >
< identical chunk >
< non-identical chunk 2 >
< identical chunk >
< non-identical chunk 3 (last 4 chars) >
-----END PGP PRIVATE KEY BLOCK-----

A --list-packets on any two exports shows a difference in two lines:

iter+salt S2K, algo: 7, SHA1 protection, hash: 2, salt: < variable hex string >
protect IV: < variable hex string >

If the above is normal, then why is that - why is each export different? And what are you backing up when you export your private key for safe keeping? If it's abnormal, then what causes it, and what steps can I take to address it?

I couldn't find anything in RFC 4880 about the "protect IV" line.

Note: My question has some similarities to this one, and this one.

Improve this question
3
  • 1
    if the private key is encrypted and the encryption uses random salt, every encryption of the same key using the same password would still result in different serialization. – Z.T. Jul 6 '19 at 21:14
  • And the last 4 characters are a checksum over the preceding data, so very likely is automatically different too. – Henno Brandsma Jul 6 '19 at 21:43
  • Duped by security.stackexchange.com/questions/230450/… – dave_thompson_085 Mar 14 at 19:41
3

The exported private keys are encrypted using a password (by default, at least). This means that the private parameters have been encrypted with a key derived from that password plus a randomly generated 8 byte salt. The standard modes of operation for the chosen cipher (like CFB or CBC) also have a random IV (of the block size, so 8 or 16 bytes, depending on whether CAST5/3DES etc. have been used or AES).

Both the salt and the IV will modify the bulk of the private key to be quite different. So it's by design, to hinder some password bruteforcing attacks (always the same salt would mean we could precompute tables for common passwords and dictionaries etc.)

Improve this answer

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.