GnuPG / OpenPGP: How to eliminate redundancy in PGP private key?

Question

I examined a few randomly generated private keys generated by Gnu PG, and found a lot of redundancy.

1. It is enclosed by -----BEGIN PGP PRIVATE KEY BLOCK----- and -----END PGP PRIVATE KEY BLOCK-----
2. There is a CRC checksum at the end (e.g., =WXYZ)
3. All RSA keys that I generated start with "lQ"

I tried removing the checksum and the importing works. Also, removing the BEGIN/END markers and the common "lQ" prefix seems reversible. I am wondering how much further can I go to make the key less redundant and more obfuscated?

My main security concern is:

If the attacker steals the encrypted private key, he can (more) quickly and easily verify that the decryption succeeded (in the case above, by verifying it begins with "lQ" and that the checksum is right).

Note: I used the gpg -a --export-secret-key, but it looks the non-ASCII encodeded key (no -a) has pretty much the same redundancy (I verified this using a hex editor).

Is there a specification / standard that specifies which parts of the private keys are "truly secret", and which one serve as a descriptor, checksum and can be safely removed (provided that I trust trust the key is unmodified)?

Answer 1

OpenPGP is defined in RFC 4880, which probably is the specification you're looking for. OpenPGP files (no matter whether binary or ASCII-armored) are composed of individual packets, each having a header (that is probably what you have been observing regarding the "IQ").

In an OpenPGP secret key packet, quite a lot of meta data is stored. As it also contains the public key, expect the user ID packets to be included - if these are the same, there will be more redundancy.

For working out the parts not specific to RSA keys of given size, better work with binary files instead of ASCII-armored ones (you're closer to the values given in the specifications). Very helpful at dissecting OpenPGP files will be gpg --list-packets, which dumps the contents of each packet in a more human-readable version, but also gives you packet identifiers and similar data you can look for in a hex editor.