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:

< 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) >

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.

  • 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.
    Commented Jul 6, 2019 at 21:14
  • And the last 4 characters are a checksum over the preceding data, so very likely is automatically different too. Commented Jul 6, 2019 at 21:43
  • Duped by security.stackexchange.com/questions/230450/… Commented Mar 14, 2021 at 19:41

1 Answer 1


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.)

You must log in to answer this question.

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