There are currently not enough keysafe servers. We need at least 3 for keysafe to work. Please contact firstname.lastname@example.org if you would like to run a keysafe server.
Keysafe's server list puts servers in three categories:
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.
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.
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.
-----BEGIN PGP SIGNED MESSAGE----- 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 <https://puri.sm/warrant-canary/>, and is updated quarterly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJYF8U4AAoJECPPLj0lRRT30CkP/Rn2TAeriNWO9wZcr0OHyX7B TJcgLy3pZXbGn6T6qmJqg3K22fTKJ7CX0dfIM+WLI9FfBtnT95q1rnzywhBGPXzj eD3g7r3QinIfMLBQTKyc9Ik5132uenD5h72ggVl3D+kuWv622IhaAaiVkuHc5KoR 3/S+ImkcS/gz83UNTXnWdMs0V8+eqAjpWeYQS8Ih28AECI9f+xUUH//V9Ii/4Usv E3Y0hbqj8kSi4/Q6IwmFiJTKZ1FpccKhl6GIYUSLwJMJDHoI46M/AaZy0Xx9pLcU niSELai/7/0fY4N0TY2CbZUgH7FEhi0k8cCsGF7yTA6dqya8deKQKdUdDllcHayv +GOAqijiSTPrRox4TPMMdurPXTsJxeJuxVdS75Lw2cFk+JaaIVS/3XEyeuGpaVKW wSTltyFkMx9ur5cCPT2rxoRN78HuqgiHda/Jd4c2pny7GwpUEYAznQQaBYEl2jlQ /Go3ZudpnWfBRRe7znazhA6mIatPY61GrNIebVlET6/NCw9sZFRjHXY3pMw1u/TY 4eP0UQpBUed4/sot5vsZVwbn8e6eFh0S4HTdl5x1G8jN8nUZVdJJjOtACrONW+TG CLSNDkMgQ5slBmtZm+MzL2VYkFHCMmPerNXY1DhHjMyfLpQEIN+bho+mIyc5h/W/ Br5jFZujcQ0u7GzqvaDB =RmK4 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 keysafe.joeyh.name 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. -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJXx0qFAAoJEMkQ2SIlEuPHyGMQALSLL7LZEpTi+zf2kPYGoBMQ 3z3FDB9B6SaF4uN3r+XlAw2Vzas2KVLCbNkO+np7tLzC0qdY5dBLDI7+ZJXiKi2v iqxKICl0E8+ih8JOe0JWfoysO974I1DesEI7X6VUewwNpd35OgCuIL5RmknKrX4I x7gUfsONiojUKgOT0yMErUfw3VNYB0Kbzw4Xic66eIkFl5z6APMknjqvOC1196v9 BW0rSM+OsthB9xkj7ULKQv+1LrxmwNu0+FL62qNKGObbXHayfLBGm8TT9Y7etQYD 3zRDiUfa0m2aYu7ZRx5HSIgExVVd3YosDUFA4xsIb6N4wBbP1zS2TG2Zo5o/+3gt BerkQL/xkMWhIMVCYp1hWc47MenHk1MJU5EhS+duL/fnlqW2HcFanM+fOv+/ZWt6 da2mdjSR95Ekq22BXN9eHO54AFJKLWYNdT9E5W2rlwqUoC4dqsqYGT3XWnAaKHC/ he9+B/wdEf7165Qy+MKo/36Ib7pfhPQv4hip2cuMP9w0E6JoKZusBV5AdxRvGAGf GvUhvNog6v9/t+cqUp6dSTT2WVllkXJ/5deGJYLzZMJjZS3cZ75ZKr8OD5oQxr+m 7oL6BDvxha7Q4qHo/RZgxyd/qZ7zWHTT6Tn6qNCBGUi4b6Etb0kEd5Os66WoLCSK lhmhvShr0WRqB8fWYPkc =SNGN -----END PGP SIGNATURE-----
Provided by Marek Isalski at Faelix.
Currently located in UK, but planned move to CH.
Vetting to Recommended level in progress.
- 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.
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.
It's early days still, but keysafe's server code works well enough.
git clone git://git.joeyh.name/keysafe
- Be sure to verify the gpg signature of the git repository!
- You will need to install keysafe from source; see its INSTALL file.
make installto 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 email@example.com to get added to keysafe's server list.
Here's a the propellor config for my own keysafe server: http://source.propellor.branchable.com/?p=source.git;a=blob;f=joeyconfig.hs;h=15a00f7c2dffa15ed275fdd44e84e2edcc226559;hb=b9f87f0c08d94c5d43224a2c6bbacb332ebfc1b6#l460 --Joey