Skip to content

pgp.md

Latest commit

 

History

History
197 lines (125 loc) · 6.05 KB

pgp.md

File metadata and controls

197 lines (125 loc) · 6.05 KB

Pretty Good Privacy (PGP) / GnuPG (GPG)

Primary (aka master) key and subkeys

It is possible to create private keys in a way so that they have a particular relationship.

TODO

Statement: Subkey derived from primary key is used a couple of times below. Most probably this is not correct, that is, the subkey can be certified by a primary key, and not derived from it. See here.

Namely, it is possible to create first private key, called primary key, and then a second private key, called subkey, that is derived from the primary key.

The benefit of this scheme is that:

  • subkey is like a normal key in that it can be used for signing or encryption,
  • primary key can reside on an isolated machine and is only used for deriving subkey(s),
  • if a subkey is lost or compromised, it is only the subkey that needs to be revoked -- and a new subkey can be again derived from the safe primary key.

One can think of the above as of a Certification Authority, where root key is (should be) only used to sign intermediate keys, which in turn are used to sign end entities keys.

GnuPG actually uses a signing-only key as the primary key, and creates an encryption subkey automatically. Without a subkey for encryption, you can't have encrypted e-mails with GnuPG at all.

References:

Signing vs certification

Signing is an action against arbitrary data. Certification is the signing of another key. Ironically, the act of certifying a key is universally called key signing.

References:

Usage flags (capabilities) of a key pair

It is possible to set custom capabilities to the public/private key pair.

The following capabilities are available:

  • [C]ertify (only for primary keys) - allows the key to create subkeys, mandatory for primary keys.

  • [S]ign - allows the key to create cryptographic signatures that others can verify with the public key.

  • [E]ncrypt - allows anyone to encrypt data with the public key, that only the private key can decrypt.

  • [A]uthenticate - allows the key to authenticate with various non-GnuPG programs. The key can be used as e.g. an SSH key.

In the output of gpg --list-keys and elsewhere, these capabilities are shown abbreviated to the first letter and in square brackets, e.g.:

  • [SC] - meaning sign and certify capabilities,
  • [E] - meaning encrypt capability.

Changing key usage flags

Use change-usage command to change the usage flags:

$ gpg --edit-key <KEY-ID>
gpg> change-usage
Changing usage of the primary key.

(...)

gpg> save

To change a subkey, select it with:

gpg>key <N>

prior to issuing change-usage command.

References:

RSA-2048, 3072, 4096

NIST states that RSA-2048 gives roughly 112 bits of security and RSA-3072 gives roughly 128. There is no formal recommendation on where RSA-4096 lies, but the general consensus is that it would come in somewhere around 140 bits - 28 bits of improvement over RSA-2048. This is an improvement so marginal that it's really not worth mentioning.

If you need more security than RSA-2048 offers, the way to go would be to switch to elliptical curve cryptography - not to continue using RSA.

References:

Per-device private subkeys

Having per-device private subkeys would allow, in a case of a key compromise, to revoke only the key used for the particular machine -- the one on which the key has been compromised. All other keys could be kept without revoking.

Due to the nature of implementation, the following good practices hold true:

  • use a per-device signing subkey,
  • use a single encryption subkey, common to all devices.

It is not a good practice to have a per-device encryption subkey. This is because the default enceryption key selection algorithm is to use the newest key available. Senders will simply use the newest key available and there is not much that can be done about that.

TODO

Write note about signing key selection algo.

References:

Working with NOT IMPORTED key files

Brief peek at an OpenPGP key file

$ gpg -vv keyfile.asc

Verify and list the fingerprint of the key

$ gpg --with-fingerprint --with-subkey-fingerprint keyfile.asc

Working with imported keys

Listing keys

$ gpg --list-keys

Change the passphrase of the secret key

$ gpg --edit-key <KEY-ID>
gpg> passwd
gpg> save
gpg> quit

Encrypting a message (pubkey)

To encrypt a message using public key cryptography, the public key of the reci- pient(s) is needed:

$ gpg    -e -r <RECIPIENT-KEY-ID> -o <ENCRYPTED-FILE.asc> <CLEAR-TEXT-FILE>

Using ASCII output (default is binary):

$ gpg -a -e -r <RECIPIENT-KEY-ID> -o <ENCRYPTED-FILE.asc> <CLEAR-TEXT-FILE>

Signing a message

To sign a message, the private key of the sender (you) is needed. By default, GPG selects a default signing key -- which might not be what you want if you have multiple keys.

To sign a message, using a particular key:

$ gpg [-a] -s -u <SENDER-KEY-ID> -o <SIGNED-FILE.asc> <UNSIGNED-FILE>

Exporting keys

Export public key(s):

$ gpg [-a] --export                [-o KEY-FILE.pub] [KEY-ID]

Export private key(s);

$ gpg [-a] --export-secret-keys    [-o KEY-FILE.key] [KEY-ID]

Export private subkey(s):

$ gpg [-a] --export-secret-subkeys [-o KEY-FILE.key] [KEY-ID]