wallet/docs/gpg_subkeys.md

---
title:
    Gpg subkeys
sidebar: true
...

# To set up a system with gpg subkeys but without the master key

This is horribly painful, and we need to create a better system and eat our
own dogfood.

We ignore the Gpg Web of Trust model and instead use the Zooko identity model.

We use Gpg signatures to verify that remote repository code is coming from an unchanging entity, not for Gpg Web of Trust.  Web of Trust is too complicated and too user hostile to be workable or safe.

Never --sign any Gpg key.  --lsign it.

Never use any public gpg key repository.

Never use any email address on a gpg key unless it is only used for messages relating to a single group and a single purpose, or a fake email.

Gpg fundamentally lacks the concept of one entity acting for and on behalf
of another.  A subkey should be identified by the name of the master key
followed by a subname intelligible to humans, and a sequence of grant of
authority values intelligible to computers, represented by either a variable
precision integer representing a bit string, each bit corresponding to a an
authority value, which bitstring may contain a flag saying that further
authorities are represented by a null terminated Dewey decimal sequence rather
than by one bits in a sparse bitstring.

But for the moment:

```bash
gpg --expert --full-gen-key
```

Select 9 ECC and ECC, then select curve25519, then 0, key does not expire.
(This is going to be the rarely used master key, whose secret will be kept in
a safe place and seldom used)

Much open source cryptography has been backdoored.  I have no reason to
suppose that gpg is backdoored, other than that there is a great deal of
backdooring going around, but I have positive reason to suppose that
curve25519 has *not* been backdoored in gpg, and even if I did not, the
fewer cryptographic algorithms we use, the smaller the attack surface.

Gitlab strongly recommends using only ED25519 ssh keys to interact with
git repositories, and I strongly recommend using only ED25519 ssh keys
to interact with repositories and only 25519 gpg keys to authenticate
commits and identify committers.  I mention Gitlab not because I regard
them as a highly authoritative source, but to show I am not the only one
around who is paranoid about broken and corrupted cryptographic code.

Everyone should use the same algorithm to reduce the attack surface.

Name `«master key»>`  (use a fake email address)  Gpg was designed to
make email secure, but email is not secure.  We will be using this as the
root of identities in Git, rather than to authenticate email.  Use this root of
identity only for project related matters, only for the authentication of code
and design documents.  Don't use this identity for other purposes, as this
will increase the risk that pressure or unpleasant consequences will be
applied to you through those other activities.  Don't link this identity to
your broader identity and broader activities, as pressure is likely to applied
to introduce hostile code and strange design decisions that facilitate other
people's hostile code.  This happens all the time in projects attempting to
implement cryptography.  They get one funny feature after another whose
only utility is facilitating backdoors.

gpg will ask you for a passphrase.  If your keyfile falls into enemy hands,
your secret key is subject to offline dictionary attack, against which only a
very strong passphrase, with about 128 bits of entropy, can protect it.
Which is a problem that crypto wallets address, and gpg fails to address.
Either use a strong non human memorable passphrase or else use a trivial
passphrase or no passphrase, and instead export and  hide the secret key
file and delete it from gpg when you are done.  A human cannot remember
a strong passphrase.  Write it down, in pencil, and hide it somewhere.
(Pencil does not fade, but some inks fade)  If you can remember the
passphrase, and someone gets at your keyfile, it is unlikely to protect you
keyfile.  A strong passphrase looks like a wallet master secret.

Gpg's passphrases are merely a nuisance.  They fail to serve a useful
purpose if used in the manner intended.  Wallets came under real attack,
and now do things correctly.  One of our objectives is to replace gpg for git
and gpg for secure messaging with something that actually works, with a
wallet, but for the moment, we use what we have.

Now create another similar subkey.  This time give it an expiry date in the
near future

```bash
gpg  --expert --edit-key «master key»
addkey
```

Rather than protecting your primary keys with a useless password, you
should export them to a safe place, such as a pair of thumbdrives, and then
delete them, to be re-imported when you need them to add a new subkey
when your subkey expires.

```bash
save
gpg --list-keys --with-subkey-fingerprints --with-keygrip «master key»
gpg -a --export  «master key»
gpg -a --export-secret-keys  «master key»
```

Then look in at the secret keys listed by keygrip in
`$HOME/.gnupg/private-keys-v1.d/KEYGRIP.key` and delete any
secret keys of the master key other than short lived subkey you just
added.

```bash
gpg --list-keys --with-subkey-fingerprints --with-keygrip «master key»
# secret keys that have already been deleted will be marked with a #
```

 You should make sure that any secret keys with no expiration or an
 expiration in the distant future are marked with that sign, and if they are
 not, delete them.

On non airgapped machines, you will delete the primary key, or not
import it in the first place.

After all  this complicated, easy to get wrong, and confusing rigmarole,
you should, upon importing and trusting, have a copy of gpg that can sign
commits with your short lived subkey as an agent for your long lived
master key.

Git can now still sign with the non expiring master key, because it still has
a subkey that will expire in the near future.

[sovereign corporations]:social_networking.html#many-sovereign-corporations-on-the-blockchain

We need to replace this with our own system and make life a whole lot
simpler for someone with a shortlived subkey on a cloud computer and a
master key offline or on an airgapped computer.

Making life simpler for ourselves is a step towards making life
simpler for someone who is likely to give us money.

This an important eat-your-own-dogfood job.  But doing it right, rather
than  a user hostile patch on a patch, is likely to be hard, because rewriting
Git to use our keys and our identities is likely to be an enormous job. Git
also needs fixing, not only because it uses the domain name identity model
rather than secret key but because it uses an insecure hash.

Obviously we need to eventually replace all this complicated rigmarole
with a system whereby one identity on one wallet can send a message to
another identity on another wallet granting it an identity with authority to
act as agent for the first identity.  The primary use case for such a system is
not signing code, though that will be our first use of it, but to enable
[sovereign corporations] to act through remote employees and safely use
servers in the cloud.  Information wants to be free, but programmers want
to be paid.