Zcash: Generate offline software signing key

[ageis]

This is related to #1034, #540 and #1379.

When we are better positioned to provide binaries and .deb packages, we need a key to sign them with.

My recommendation is that Zcash's master software signing key be created and stored on an air-gapped computer. We should determine which developers are responsible for making signatures and holding a copy of the key. Possibly we could even apply Shamir's secret sharing so that signing is a ceremony requiring the participation of multiple people possessing parts of the private key.

It would be acceptable to load the key onto a smartcard in order to facilitate signing from internet-connected build machines.

The public key should be published prominently somewhere on our website. We can also provide a keyring package for Debian in order to ease updates if the key ever needs to be rotated or revoked. The expiry should be set to something like 1 year, and we can periodically update the expiry as we are assured of the key's security.

[sampablokuper]

Also related to #609 AFAICT.

[sampablokuper]

My recommendation is that Zcash's master software signing key be created and stored on an air-gapped computer. We should determine which developers are responsible for making signatures and holding a copy of the key. Possibly we could even apply Shamir's secret sharing so that signing is a ceremony requiring the participation of multiple people possessing parts of the private key.

This is in essence a good proposal. A few notes:

• Air-gapping is not a total panacea. See Stuxnet, for example. Other side channels should also, ideally, be accounted for, such as acoustic, optical, and electrical.

It _is_ a good idea to use an air-gapped and side channel-protected computer for key generation, and for any signing ceremonies that require the master signing key itself and not just its subkey. However, it is _not_ necessarily a good idea to use such a computer as a storage medium, because typical laptop or desktop PCs are:
- not tamper-evident;
- re-writable;
- bulky to store;
- vulnerable to fire, flood and theft;
- hard to split into shares.

Therefore, a better option might be to store the _master signing key_ (or its shares) encrypted on read-only optical discs such as CD-Rs burned in "disc-at-one" mode, with encrypted paper keys as back ups. These could then be kept in fireproof safes at suitable locations.

• With respect to secret sharing, some consideration should be given to:
  
  
  
  • which sharing algorithm to use, e.g. verifiable secret sharing, proactive secret sharing, etc.
  
  
  • whether it is the _master signing key_ that should be split into shares, or the passphrase for that key, or both.
  
  
  • who should hold which revocation certificates, and in what form.
  
  

Whichever decisions are made on these fronts, the justification for those decisions should be publicly announced for accountability.

For additional accountability, key generation and/or signing ceremonies should be publicly broadcast live, e.g. as per the IANA.

It would be acceptable to load the key onto a smartcard in order to facilitate signing from internet-connected build machines.

It is _not_ a good idea to store the master signing key on a smartcard. If anyone were to misplace such a smartcard, the key stored on it would definitely have to be revoked, because de-capping smartcard chips and reading their contents is a profession whose practitioners have a reasonable chance of success. Revoking the master signing key, after it is published and has been in real-world use, would be a serious blow to Zcash's credibility.

However, to make it practical for senior Zcash developers to sign tags and releases, it probably does make sense to store the master signing key's _signing subkey_ separately on a smartcard for this use, as per FSFE guidance. Such a subkey should, of course, be revoked if the smartcard were lost or if the subkey's passphrase were compromised through malware or eavesdropping, but this would be less of a blow for Zcash than having to revoke the master signing key itself.

[ageis]

We have an offline master software signing key (4096-bit RSA): 0x63C4A2169C1B2FA2

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQINBFgGZnIBEADM5q4NOG344jG5tAa9KvtZRE3bbpRKWVDd7SnJAPdEDgvID0n3
ACVVASysUleuY4RGBTifeKX4izF/pL7PindcenMmGrg3OiNhGgdNgNh0GIcMhXyu
71lBaXYcXIFWllzXOoeARPnK5vUh2OyzsqjlFrZjAHrr7b732cNciv0y9ECwaJf7
EQ7GqvRbi+3tuuCQfv/wC3OOPmj0GMICWtkCyXuHHEdNL59SwkpxTUhfAfsdoH3I
y74bjqk4KNcrDhFdzH1qK1+aqIRnWQqgiPvIdsccD1zuYew1Te5tXa2iLiBTgOew
nDxvucyc+u9nwXGLdGJoz17rYtXgo8o7pWPp26aCSi7CmB9DYBhF4JVEB3388IF3
jH5oTPFT2jfCUa1NtQ9iC0jjS2nxDh1nbdyTT0surW+I7L+8HnkhDD1ccdEXcsAf
lKMz7MijLF9Yy4nQaMc++R85rWDhqaqKDx7w62TX13lMJ1ZqNW4WUN1vdn1RpnN3
DCHkNZL5LyXfg2IVq1IaN1caJI0JYUo1r6ykc1qW05iaUNEKpwBYMo4+RVyYCJgK
EdxHIHr5X0LPDVaL8T6jV6on8vmwyrBlvIFZP1/OC9JOz0alDi/xqvsXF5RvKsPQ
ewbwrRTZOGuSspHMHUdK/oi0niSMJkNe3G8iICyVJU/KSCgdvx3TphHE+wARAQAB
tBhaY2FzaCBNYXN0ZXIgU2lnbmluZyBLZXmJAj0EEwEKACcFAlgGZnICGwMFCQPC
ZwAFCwkIBwMFFQoJCAsFFgIDAQACHgECF4AACgkQY8SiFpwbL6KElQ//e3Nh0RQK
gAfDmLS7kh5FDA3PPQDEssfIcdPGqD4jSTOKZTEn98jl5VfyarRJw6gnkkTnzSHA
hbt9hcTcu9m7G4X+UvHfTfUffYpYoN1A/VqeZ1Li+xrLdWMTNldVRSjf0mIgtJW9
izbkf7GKRI5IZ6GZPLovHrtsZY+ocZ9r9MzvUSxVIw2nCw7os4mgPEcp/PvagUS+
JcGL4qZRRe2MzKY4GN5uYpcVur55+xVjjnaHjHhczZwg8WyjwbnjhP/XgR9Ag7nQ
Cw27S1g29zx7GOamkgSz9/BSDxPq7bmm1gurgjRTatXdSxv8kPvk1NGRqXwZkEp1
GYLZz/AqZHuzFMwlnn2twU/ayYHta5ywpX0nNO+n+PdZ9etNdH+W5UIBRMovK3nm
HrtDEpyGYBElOhGZiDWJMrCe7MJH3n1h6ntYMNZZm2M5mkg3P3AO5J7DahwQjz+F
fVFq+B10j9o7x349/0CKmJdtt+DvfXgPLsf//zq4uX+Mvt/JrNUkcFYJtDFdmJQA
y7jpKy8PijIcPRM4IQx1oEbJUYAVi4qvurr80s6r+IVOiryNcPdWHmgR2JuALQL5
FxJx70IzdJEyd8l/ohp1Q05Z7gQdCKliQzAOqHrx1sgsrJdk424U+CSSgmhKxtFp
JPbGDprzBUyDHC+tn4Poz7qxFPwqLeRTfxE=
=YKuG
-----END PGP PUBLIC KEY BLOCK-----