There are currently not enough keysafe servers. We need at least 3 for keysafe to work. Please contact if you would like to run a keysafe server.

Server categories

Keysafe's server list puts servers in three categories:

  1. Recommended: Servers that meet all best practices for security and are run by a well-known, trusted entity.

    Keysafe prefers to store data only on Recommended servers when possible.

  2. Alternate: Servers that are not secured well enough to be Recommended.

    Keysafe will store data on Alternate servers if it has to, but will avoid storing enough data to allow the key to be recovered using only the data stored on Alternate servers.

    For example, with 2 of 3 shares needed to restore a key, keysafe can store 1 share on an Alternate server, and the other 2 shares on two Recommended servers.

  3. Untrusted: Servers that are not secured well or are run by an untrusted entity.

    Keysafe will never store data on Untrusted servers.

    If a server becomes untrusted and keysafe stored data on it in the past, keysafe will warn the user about this problem.

    The only time keysafe will use untrusted servers is if it's restoring a key, and cannot find enough shares on Recommended/Alternate servers, and has to fall back to downloading from an Untrusted server.

Server list



Hash: SHA1

The keysafe server hlmjmeth356s5ekm.onion is provided and administered by
Purism. It is located in the EU (Cyprus).

We intend to run this server for at least 10 years (through 2027),
or failing that, to transition any data stored on it to another
server that is of similar or higher security.

Our warrant canary is <>,
and is updated quarterly.
Version: GnuPG v1


(Unfortunately, Purism's keysafe server went down at some point before 2020. Hopefully they will bring it back and meet their commitment above.)


Hash: SHA256 is provided by me, Joey Hess.

  I intend to run this server for at least 10 years (through 2027),
  or failing that, to transition any data stored on it to another
  server that is of similar or higher security.

  It is a Digital Ocean VPS, located in Indonesia. I can't tell if the
  hosting provider is accessing the contents of the server, and so
  this server is not securely hosted enough to be Recommended.



Provided by Marek Isalski at Faelix. Currently located in UK, but planned move to CH.
Vetting to Recommended level stalled several years ago.

Detailed requirements


  • Keysafe port only exposed via tor hidden service.
  • Dedicated to only running keysafe, no other services. (Other than tor and ssh for admin)
  • The set of people who administer the server, and procedures for giving others access is well-defined.
  • Noone who has access to the server also has access to any Recommended server.
  • Commitment to either keep the server running long-term (ie, 10+ years), or transition the data to a replacement server that meets these requirements and that must not contain any related shards.
  • No other open ports (other than ssh).
  • Ssh authentication only by ssh key, not password.
  • Either off-server backup, or replication of shards to additional disks. (rsync to additional local disks would work perfectly well and avoids the complications of RAID)
  • Any off-server backup is strongly encrypted. (There's a trade-off here; any backup widens the attack surface. It may be better to run some servers without backups and adjust the number of shards needed to recover keys; a server losing its data need not be catastrophic.)
  • Any backup should take care to not leak information about what objects were present on the server at multiple times in the past. That would let an attacker who can access the backups make guesses about shares belong with other shares stored on other servers in the same time period. See details for how that makes it somewhat easier for an attacker.

    keysafe --backup-server can be used to generate encrypted files to back up, in a way that is designed to avoid these problems.

  • Similarly, the filesystem and storage system should not allow rolling back to old snapshots.


  • Everything in Alternate, to start with.
  • Run by a well known and trustworthy entity.
  • Noone who has access to the server also has access to any other Recommended or Alternate server.
  • Warrant canary.
  • Hardware is hosted in-house. A VM at a cloud provider is right out because the provider could be made to give access to it without the server operator knowing about it. Which would bypass the warrant canary.
  • The keysafe data store and any swap partitions are encrypted, and have to be manually unlocked when the server is booted.

Server scaling

Each key takes a minimum of 64 KiB to store, perhaps more for gpg keys with lots of signatures. So 10 GiB of disk is sufficient for 160 thousand users, which is enough for a small keysafe server.

The keysafe server uses very little memory and CPU. It does rate limiting with client-side proof-of-work to prevent it being abused for general-purpose data storage.

There is some disk IO overhead, because keysafe updates the mtime and ctime of all shards stored on the server, as frequently as every 30 minutes. Once a large number of shards are stored, this could become a significant source of disk IO.

Server setup

It's early days still, but keysafe's server code works well enough.

  • git clone git:// keysafe or git clone
  • Be sure to verify the gpg signature of the git repository!
  • You will need to install keysafe from source; see its INSTALL file. Use make install to install it, including a systemd service file.
  • systemctl enable keysafe.service
  • Install tor and set up a tor hidden service. Keysafe listens on port 4242 by default, so use that port.
  • Configure the server to meet all the requirements for Alternate or Required.
  • Once ready, email to get added to keysafe's server list.

Here's a the ?propellor config for my own keysafe server:;a=blob;f=joeyconfig.hs;h=15a00f7c2dffa15ed275fdd44e84e2edcc226559;hb=b9f87f0c08d94c5d43224a2c6bbacb332ebfc1b6#l460 --?Joey