Differences between revisions 14 and 16 (spanning 2 versions)
Revision 14 as of 2017-09-08 13:07:39
Size: 4735
Comment: Add subtitles + link to mail list archives + minor rewording.
Revision 16 as of 2017-10-09 13:08:49
Size: 4773
Editor: ?umlaeute
Comment: fixed typo "will" -> "while"
Deletions are marked like this. Additions are marked like this.
Line 4: Line 4:
''Large parts of this page originate from [[https://lists.debian.org/debian-project/2017/08/msg00011.html|a discussion on the debian-project mailing list]].  See the info page for attributions.'' ''Large parts of this page originate from
[[https://lists.debian.org/debian-project/2017/08/msg00011.html|a discussion on the debian-project mailing list]].
See the info page for attributions.''
Line 6: Line 8:
Using [[Subkeys|subkeys]] and keeping the master key offline reduces the risk
that it is stolen. Subkeys can be revoked easily without compromising
the master key and losing its connection to the web of trust.
Using [[Subkeys|subkeys]] and keeping the master key offline reduces the risk that it is stolen.
Subkeys can be revoked easily
without compromising the master key and losing its connection to the web of trust.
Line 14: Line 16:
Create a certification only master key (1) using something like PGP Clean Room
on a non-networked host, and store that on a USB key you only ever put
into your machine
when running your clean, non-networked,
environment.  Encryption of the filesystem provides additional
security (2).  Create at least 2 [[Subkeys|subkeys]] - signing + encryption -
and use those in your day to day work. You then only need the master key
when dealing with signing other keys, or updating your subkeys. In
the event of your subkeys being compromised or lost or whatever you
can just regenerate; because your master key is offline it should
remain secure
meaning you don't have to go through the pain of
getting cross signatures again.
Create a certification only master key (1)
using something like PGP Clean Room on a non-networked host,
and store that on a USB key you only ever put into your machine
when running your clean, non-networked, environment.
Encryption of the filesystem provides additional security (2).
Create at least 2 [[Subkeys|subkeys]] - signing + encryption -
and use those in your day to day work.
You then only need the master key
when dealing with signing other keys, or updating your subkeys.
In the event of your subkeys being compromised or lost or whatever
you
can just regenerate;
because your master key is offline it should remain secure
meaning you don't have to go through the pain
of getting cross signatures again.
Line 28: Line 33:
If you want to buy hardware then one of the self contained USB
tokens
that look like a smartcard + reader to the OS is probably
easiest. Unfortunately, most (all ?) only
supports 3 keys on the device and those are one each of signing,
encryption + authentication. Which means one can't have a master
certification key and a signing subkey on the same device.
Thus, if you can manage it, have 2 devices; one with the master and the
other with your day-to-day keys. Otherwise having a master
key that is signing enabled might be the best option.  Some dongles
can be configured to remember the passphrase for some time.  It may
be better to not remember the one of the signing key, but remembering
the one of the encryption key for short while may be acceptable.
If you want to buy hardware then one of the self contained USB tokens
that look like a smartcard + reader to the OS is probably easiest.
Unfortunately, most (all ?) only supports 3 keys on the device
and those are one each of signing, encryption + authentication.
Which means one can't have a master certification key and a signing subkey on the same device.
Thus, if you can manage it, have 2 devices;
one with the master and the other with your day-to-day keys.
Otherwise having a master key that is signing enabled might be the best option.
Some dongles can be configured to remember the passphrase for some time.
It may be better to not remember the one of the signing key,
but remembering
the one of the encryption key for short while may be acceptable.
Line 43: Line 47:
 * [[http://www.fsij.org/doc-gnuk/intro.html#what-s-gnuk|Gnuk]]: Supports RSA4096 (but is slow). The [[http://www.fsij.org/doc-gnuk/intro.html#target-boards-for-running-gnuk|hardware]] is open (3). The software is open (you can compile and flash it using tools available in main).  Upstream is responsive (and a DD). However it's physically not quite as polished and there are availability issues.

* Nitrokey Start: Based on the GnuK (note their other devices are not) and might be more physically robust will still being reasonably Free.  (The Nitrokey Pro uses a non-free smartcard internally for the RSA operations.)

* !YubiKey: Recent ([[Smartcards/YubiKey4|YubiKey 4]]) models are entirely closed. However they're easily available and physically robust.  The !YubiKey Neo does not support 4096-bit RSA keys.
 * [[http://www.fsij.org/doc-gnuk/intro.html#what-s-gnuk|Gnuk]]:
Supports RSA4096 (but is slow).
The [[http://www.fsij.org/doc-gnuk/intro.html#target-boards-for-running-gnuk|hardware]] is open (3).
The software is open
(you can compile and flash it using tools available in main).
Upstream is responsive (and a DD).
However it's physically not quite as polished and there are availability issues.
 * Nitrokey Start:
Based on the GnuK (note their other devices are not)
 and might be more physically robust, while
still being reasonably Free.
(The Nitrokey Pro uses a non-free smartcard internally for the RSA operations.)
 * !YubiKey:
Recent ([[Smartcards/YubiKey4|YubiKey 4]]) models are entirely closed.
However they're easily available and physically robust.
The !YubiKey Neo does not support 4096-bit RSA keys.
Line 51: Line 65:
 * Which key goes on the paper slab that everybody uses to collect signatures?  * Which key goes on the paper slab
that everybody uses to collect signatures?
Line 53: Line 68:
The certification master key's fingerprint.   The certification master key's fingerprint.
Line 57: Line 72:
The master key. When it is revoked, every subkey is revoked as well. Also, using master key any subkey can be revoked.   The master key.
When it is revoked, every subkey is revoked as well.
Also, using master key any subkey can be revoked.
Line 61: Line 78:
The '''public''' portion of ''every'' key (master and all subkeys) go into
the public keyrings and also in the Debian keyring. GnuPG will handle
this automatically with the `--export` option (do ''NOT'' confuse with a
different export option that is for private keys).
  The '''public''' portion of ''every'' key (master and all subkeys)
 
go into the public keyrings and also in the Debian keyring.
GnuPG will handle this automatically with the `--export` option
 
(do ''NOT'' confuse with a different export option that is for private keys).
Line 68: Line 85:
Only the public keys (all of them: master and subkeys). GnuPG will
handle this automatically if you use `--send-key`.
  Only the public keys (all of them: master and subkeys).
GnuPG will handle this automatically if you use `--send-key`.
Line 74: Line 90:
(1): A sign and certify master key could be useful to sign messages when one had to revoke every subkey and adding new subkeys is subject to a delay, for instance to explain to someone else the need for a new subkey or to sign votes or uploads in emergency.  However, a certify-only master key forces its owner (1): A sign and certify master key could be useful
to sign messages when one had to revoke every subkey
and adding new subkeys is subject to a delay,
for instance to explain to someone else the need for a new subkey
or to sign votes or uploads in emergency.
However, a certify-only master key forces its owner
Line 77: Line 98:
(2): Encrypting a USB device (memory card, ...) hides the fact that it
contains a GPG key.  When creating a LUKS filesystem, pass the `--iter-time`
option
to make a brute force decryption take much longer (at the cost of
it taking slightly longer to decrypt and mount the partition).
(2): Encrypting a USB device (memory card, ...) hides the fact
that it
contains a GPG key.
When creating a LUKS filesystem, pass the `--iter-time` option
to make a brute force decryption take much longer
(at the cost of it taking slightly longer to decrypt and mount the partition).
Line 82: Line 104:
(3): Open hardware is expected to be less likely to have backdoors.  On the
other hand, the designs tend to be bulkier and less robust than the mainstream
device based on closed hardware.
(3): Open hardware is expected to be less likely to have backdoors.
On the other hand, the designs tend to be bulkier
and less robust than the mainstream device based on closed hardware.

Offline master key

Large parts of this page originate from a discussion on the debian-project mailing list. See the info page for attributions.

Using subkeys and keeping the master key offline reduces the risk that it is stolen. Subkeys can be revoked easily without compromising the master key and losing its connection to the web of trust.

Without hardware

If you don't want to buy hardware, use an offline master key. See GnuPG/AirgappedMasterKey for a comprehensive step-by-step example. In brief: Create a certification only master key (1) using something like PGP Clean Room on a non-networked host, and store that on a USB key you only ever put into your machine when running your clean, non-networked, environment. Encryption of the filesystem provides additional security (2). Create at least 2 subkeys - signing + encryption - and use those in your day to day work. You then only need the master key when dealing with signing other keys, or updating your subkeys. In the event of your subkeys being compromised or lost or whatever you can just regenerate; because your master key is offline it should remain secure meaning you don't have to go through the pain of getting cross signatures again.

With hardware

If you want to buy hardware then one of the self contained USB tokens that look like a smartcard + reader to the OS is probably easiest. Unfortunately, most (all ?) only supports 3 keys on the device and those are one each of signing, encryption + authentication. Which means one can't have a master certification key and a signing subkey on the same device. Thus, if you can manage it, have 2 devices; one with the master and the other with your day-to-day keys. Otherwise having a master key that is signing enabled might be the best option. Some dongles can be configured to remember the passphrase for some time. It may be better to not remember the one of the signing key, but remembering the one of the encryption key for short while may be acceptable.

Notes on hardware:

  • Gnuk: Supports RSA4096 (but is slow). The hardware is open (3). The software is open (you can compile and flash it using tools available in main). Upstream is responsive (and a DD). However it's physically not quite as polished and there are availability issues.

  • Nitrokey Start: Based on the GnuK (note their other devices are not) and might be more physically robust, while still being reasonably Free. (The Nitrokey Pro uses a non-free smartcard internally for the RSA operations.)
  • YubiKey: Recent (YubiKey 4) models are entirely closed. However they're easily available and physically robust. The YubiKey Neo does not support 4096-bit RSA keys.

Questions and answers:

  • Which key goes on the paper slab that everybody uses to collect signatures?
    • The certification master key's fingerprint.
  • For which keys should one have revocation certificates on file?
    • The master key. When it is revoked, every subkey is revoked as well. Also, using master key any subkey can be revoked.
  • What key goes into the Debian keyring?
    • The public portion of every key (master and all subkeys) go into the public keyrings and also in the Debian keyring. GnuPG will handle this automatically with the --export option (do NOT confuse with a different export option that is for private keys).

  • Which (set of) keys goes to the key servers?
    • Only the public keys (all of them: master and subkeys).

      GnuPG will handle this automatically if you use --send-key.

Footnotes:

(1): A sign and certify master key could be useful to sign messages when one had to revoke every subkey and adding new subkeys is subject to a delay, for instance to explain to someone else the need for a new subkey or to sign votes or uploads in emergency. However, a certify-only master key forces its owner to manage the signing subkey correctly.

(2): Encrypting a USB device (memory card, ...) hides the fact that it contains a GPG key. When creating a LUKS filesystem, pass the --iter-time option to make a brute force decryption take much longer (at the cost of it taking slightly longer to decrypt and mount the partition).

(3): Open hardware is expected to be less likely to have backdoors. On the other hand, the designs tend to be bulkier and less robust than the mainstream device based on closed hardware.