#+TITLE:
#+AUTHOR: Bob Mottram
#+EMAIL: bob@freedombone.net
#+KEYWORDS: freedombone, keyserver
#+DESCRIPTION: How to use KEYSERVER
#+OPTIONS: ^:nil toc:nil
#+HTML_HEAD:
#+BEGIN_CENTER
[[file:images/logo.png]]
#+END_CENTER
#+BEGIN_EXPORT html
OpenPGP Key Server
#+END_EXPORT
The /web of trust/ is a nice idea, but how trustable is it? If you take a look at how many OpenPGP key servers are out there then there are a two or three main ones and not much else. Can you trust those servers? Who is maintaining them and how often? Is any censorship going on? How hard would it be for adversaries to get implants onto them? In terms of technology this infrastructure is quite old and it could have been neglected for a long time. Once vigilant maintainers might have turned lazy and gotten lax with server security, or been recruited over to the dark side.
For these kinds of reasons you might prefer to run your own web of trust infrastructure. In simple terms it's a database of GPG public keys which provides a way for users to /find out how to communicate with others securely via email/. You can meet in person and exchange public keys via sneakernet on USB drives, but most users of GPG don't do that. Instead they just download the public key for a given email address from one of the key servers.
#+BEGIN_CENTER
[[file:images/keyserver.jpg]]
#+END_CENTER
* Installation
ssh into the system with:
#+BEGIN_SRC bash
ssh myusername@mydomain.com -p 2222
#+END_SRC
Select *Add/Remove Apps* then *keyserver*. You will then be asked for a domain name and if you are using FreeDNS also the code for the domain which can be found under *Dynamic DNS* on the FreeDNS site (the random string from "/quick cron example/" which appears after /update.php?/ and before />>/). For more details on obtaining a domain and making it accessible via dynamic DNS see the [[./faq.html][FAQ]]. Typically the domain name you use will be a subdomain, such as /keys.mydomainname.net/. It will need to be a domain which you have bought somewhere and own and not one of the FreeDNS subdomains, otherwise you won't be able to get a SSL/TLS certificate for it.
After the install has completed go to *Security settings* and select *Create a new Let's Encrypt certificate* and enter the domain name that you are using for the Key server. If the certificate is obtained successfully then you will see a congratulations message.
* How to use it
Interaction with the web user interface is pretty minimal and obvious, but most likely you will also want to be able to use your keyserver from the commandline. To do that use the *--keyserver* option. For example to search for a key on your server:
#+begin_src bash
gpg --keyserver [your keyserver domain] --search-keys [email address]
#+end_src
Or to send a key to it:
#+begin_src bash
gpg --keyserver [your keyserver domain] --send-keys [email address or key ID]
#+end_src
Or to get a key:
#+begin_src bash
gpg --keyserver [your keyserver domain] --recv-keys [email address or key ID]
#+end_src
* Sync with other keyservers
Key servers avoid censorship or errors by gossiping between each other and cross referencing the data. You can define which other servers your key server will gossip with by going to the *Administrator control panel*, selecting *App Settings* then *keyserver* then *Sync with other keyserver*.
It's a good idea not to try to sync with the popular OpenPGP key servers, because those have gigantic databases which may make your server unstable and certainly would make it hard to create backups within a tractable amount of time. This option is mainly intended to sync with other Freedombone systems or small home servers within a particular community.
* Possible problems
OpenPGP key servers are not very well defended from flooding attacks. This means that an adversary could just upload a billion keys to destabilize the server and fill it with nonsense to make it unusable. Since key servers are /fully open to the public/ there isn't anything to prevent that from happening.
Within the Freedombone system there is a watchdog script which keeps track of the key server database size, and disables the key server if that gets too large. Apart from the usual firewall and web server traffic rate limits, this is a crude but probably practical way of defending against flooding.
If a flood attack does happen then really the only way to recover is to restore from the last known good backup, which can be done from the *Administrator control panel*.