article about Air Gapped OpenPGP Key

adrelanos adrelanos at
Tue Nov 19 12:50:41 CET 2013

Hauke Laging:
> Am Mo 18.11.2013, 17:21:22 schrieb adrelanos:
>> Hi,
>> An article about air gapped OpenPGP keys has been written by me:
>> Please leave feedback or hit the edit button.
> ####################################
>> By default GPG creates one signing subkey (your identity) and one encryption
>> subkey
> That's wrong. The default is a mainkey for signing and a subkey for 
> encryption.

Fixed that.

>> This new subkey is linked to the first signing key.
> ?

Fixed that.

>> Your master keypair is the one whose loss would be truly catastrophic.
> I would not put it that way. If it is just lost then the key will expire (if 
> it has an expiration date as it should) as you cannot extend its validity 
> time. So you need a new key. That is unpleasant but usually not as unpleasant 
> as compromised decryption or signature keys. If you state something like that 
> I think you should explain it.

I agree with that. Originally intended to write "compromise" instead of
"loss". When I write "compromise", that sentence should be correct.

>> Using the highest possible value for key length helps protect you from that
>> scenario. Don’t use GPG’s default of 2048!
> That argument doesn't make any sense for a key "copied to your every day 
> operating system".

The whole context is:

> When you create your new keypair, use the highest possible values for
key length. As computers get more powerful and storage gets cheaper,
it’s conceivable that a nasty person could archive a message that’s
unbreakable today, then in the future break it using a more powerful
computer. Using the highest possible value for key length helps protect
you from that scenario. Don’t use GPG’s default of 2048!

Why doesn't tbhat make sense?

>> If your master keypair gets lost or stolen, this certificate file is the
>> only way you’ll be able to tell people to ignore the stolen key. This is
>> important, don’t skip this step!
> I have never understood why people seem to believe that they cannot safely 
> store a key backup (including the passphrase if necessary) but can safely 
> store a revocation certificate.

I don't understand.

>> Clean up our temporary file.
>> rm subkeys
> Why should one remove this file?

Probably not that important. It's not required anymore. When later new
subkeys are created, that file would have to be updated. Removing it to
avoid confusion.

> And it it really a good idea to use the same passphrase for both mainkey and 
> subkeys?

>From a security perspective, clearly no. From a usability perspective,
yes. Above I am suggesting to store the key backup on a fully encrypted
disk, so the passphrase for the mainkey doesn't matter if you assume,
the full disk encryption of that disk is safe.

>> The pound sign means the signing subkey is not in the keypair located in the
>> keyring.
> No, it means that the mainkey has been replaced by a stub.

I added this as a footnote.

>> Securely wiping of data is a difficult issue. We believe it is safer to
>> create a new keypair (a new secring.gpg) than trusting gpg to remove the
>> private master key from secring.gpg.
> We are talking about a secring.gpg in RAM as the key is generated on a secure 
> system running some live Linux CD/DVD?

That would be advisable.

>> Our every day operating system never gets to see our OpenPGP master key
> But it sees the mainkey's passphrase...


> It will take me some time to translate this in English but I have written a 
> bash script which creates a new key with two subkeys and outputs a set of 
> files (with different passphrases) and two directories and even allows you to 
> easily certify other keys and create mainkey signatures immediately after key 
> creation:
> 0x11DB2900.public.asc
> 0x11DB2900.public.asc.asc
> 0x11DB2900.secret-mainkey.asc
> 0x11DB2900.secret-mainkey-only.asc
> 0x11DB2900.secret-subkeys.asc
> _gnupg-mainkey/
> _gnupg-subkeys/
> explained here:
> Or download the whole script collection here and run ./

This is most interesting.

More information about the Gnupg-users mailing list