From 13e2d75c713eecf0184d621922f3f8cca4a25933 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sun, 22 Jan 2017 09:28:53 -0400 Subject: Keysafe has a new website, https://keysafe.branchable.com/ --- doc/details.mdwn | 365 +++++++++++++++++++++++++++++++++++++++ doc/faq.mdwn | 88 ++++++++++ doc/index.mdwn | 81 +++++++++ doc/news/version_0.20160927.mdwn | 20 +++ doc/news/version_0.20161006.mdwn | 10 ++ doc/news/version_0.20161007.mdwn | 9 + doc/news/version_0.20161022.mdwn | 12 ++ doc/news/version_0.20161107.mdwn | 14 ++ doc/screenshots.mdwn | 14 ++ doc/screenshots/0.png | Bin 0 -> 21991 bytes doc/screenshots/1.png | Bin 0 -> 22953 bytes doc/screenshots/2.png | Bin 0 -> 32345 bytes doc/screenshots/3.png | Bin 0 -> 30236 bytes doc/screenshots/4.png | Bin 0 -> 27423 bytes doc/screenshots/5.png | Bin 0 -> 20439 bytes doc/screenshots/6.png | Bin 0 -> 11822 bytes doc/screenshots/restore/1.png | Bin 0 -> 18277 bytes doc/screenshots/restore/2.png | Bin 0 -> 25758 bytes doc/screenshots/restore/3.png | Bin 0 -> 17254 bytes doc/screenshots/restore/4.png | Bin 0 -> 20842 bytes doc/servers.mdwn | 194 +++++++++++++++++++++ doc/todo.mdwn | 4 + 22 files changed, 811 insertions(+) create mode 100644 doc/details.mdwn create mode 100644 doc/faq.mdwn create mode 100644 doc/index.mdwn create mode 100644 doc/news/version_0.20160927.mdwn create mode 100644 doc/news/version_0.20161006.mdwn create mode 100644 doc/news/version_0.20161007.mdwn create mode 100644 doc/news/version_0.20161022.mdwn create mode 100644 doc/news/version_0.20161107.mdwn create mode 100644 doc/screenshots.mdwn create mode 100644 doc/screenshots/0.png create mode 100644 doc/screenshots/1.png create mode 100644 doc/screenshots/2.png create mode 100644 doc/screenshots/3.png create mode 100644 doc/screenshots/4.png create mode 100644 doc/screenshots/5.png create mode 100644 doc/screenshots/6.png create mode 100644 doc/screenshots/restore/1.png create mode 100644 doc/screenshots/restore/2.png create mode 100644 doc/screenshots/restore/3.png create mode 100644 doc/screenshots/restore/4.png create mode 100644 doc/servers.mdwn create mode 100644 doc/todo.mdwn (limited to 'doc') diff --git a/doc/details.mdwn b/doc/details.mdwn new file mode 100644 index 0000000..e0f85e5 --- /dev/null +++ b/doc/details.mdwn @@ -0,0 +1,365 @@ +[[!toc]] + +## Storing a key + +* Input password and name from user. The name is a combination of their own + name and a more obscure name (such as the name of their high-school + sweetheart). +* Get the keyid of the key. (This can be any a public value + unique to the private key, eg a gpg keyid. It's only used to allow + storing multiple keys under a given name. If a gpg public key is not on the + keyservers, or the key is not a gpg key, can use "" for the keyid.) +* Generate N by argon2(name, salt=keyid), tuned to take 10 minutes. +* Generate N1-N3 by sha256 of N+1,2,3 +* Generate decryption puzzle P, a byte chosen at random. +* Generate K by argon2(password, salt=name+P), tuned to take 0.195 minutes. +* AES encrypt (data + checksum) with K as the key. +* Shamir the encrypted key with N=2, M=3, yeilding S1-S3. +* Servers reject attempts to store an object under a name that is + already in use. +* Servers do not allow enumerating all objects stored, + and require a proof of work to handle any request. +* Upload S1-S3 to separate servers under the names N1-N3. + If any of the uploads is rejected as name already in use, + ask user to enter a different name or password. + +So, storing a key takes 10 minutes. + +## Recovering a key + +* Input password and name from user. +* Calculate N and N1-N2 +* Request N1-N3 from servers until two objects are available. +* Shamir recombine the objects. +* Guess a value for P. +* Generate K by argon2(password, salt=name+P) +* AES decrypt +* Repeat with new P until checksum verifies. + +This takes 10 minutes to calculate N, plus on average 128 guesses of P. +Total recovery time varies from 10 minutes to 60 minutes, with an +average of 35 minutes. + +## Difficulty of brute forcing a single encrypted key + +* Assume we know the name and keyid, or have otherwise found a way to + determine the shards of a key. Download and recombine the shards. +* Guess a password. +* For each possible value of P, AES decrypt with + K = argon2(password, salt=name+P), and check if checksum verifies. + This takes 0.195 minutes * 256 = 50 minutes total. +* Repeat for next password. + +So, for a password with N entropy, the number of CPU-years of work +is to crack it is: `2^(N-1)*50/60/24/365` + +* Strong password (50 entropy): 53553077761 CPU-years +* Weak password (30 entropy): 51072 CPU-years +* Super-weak password (19 entropy): 25 CPU-years + +So, if an attacker is able to find the right shards for a secret key, it's +feasible for them to crack super-weak and weak passwords, assuming the +secret key is worth the cost of doing do. Stronger passwords quickly +become infeasible to crack. + +## Attack methods + +An attacker who wants to target a particular person can guess the name they +used, derive N1-N3, download two of S1-S3 and start brute forcing the +password soon after the object is stored. This is the most likely attack +method, so any user who could potentially be targeted like this should +choose a strong password. A name that attackers are unlikely to guess +prevents this attack, which is why keysafe prompts for not only the +user's name, but also a more obscure name. Each name guess that the +attacker makes takes 10 minutes of CPU time to generate N, as well +as whatever proof of work the servers require. + +The sharding prevents a single malicious server from blindly +guessing weak passwords across its entire collection of objects. +It takes two servers colluding to try to recombine their shards. + +If recombining two shards yielded data which could be checked to see if +it's valid, then it would become fairly inexpensive to try all combinations +of shards, and obtain all the encrypted keys for further cracking. So it's +important that there not be any checksum or header in addition to the AES +encrypted data. (AES encrypted data cannot be distinguised from random +garbage except by block size.) Get that right, and with N keysafe users, an +attacker would need to try `2^(N-1)` combinations of shards to find one on +average, and would need to brute force the password of each combination. +With only 20 keysafe users, assuming all users have super-weak passwords, +this attack takes 13107200 years of CPU work `(2^19*25)` to crack one. With +50 users, this jumps to quadrillions of years of CPU work. + +Colluding servers can try to correlate related objects based on access +patterns and recombine pairs of those, and then brute force the password. +The correlation needs to be very fine-grained for this to work. +If 15 users' objects are all bucketed together by the correlation, +then the attacker has 16384 combinations to try on average before +finding a correct combination. Multiply by 5 years CPU work for cracking +only super-weak passwords. + +Colluding servers who want to target a particular person +can guess their N1-N3, check if those objects exist on the server, and +begin brute-forcing the password. This is not much cheaper than the same +attack performed by a third-party attacker, except that the attacker +doesn't need to wait for an object to download from the server to check if +it exists. + +A state-level entity may try to subpoena the entire contents of keysafe +servers. Once 2 servers are compromised, the state-level entity can try the +same attacks that colluding servers can use (but probably cannot use +attacks involving correlation because the server operators should not be +retaining the data needed for correlation). Of course, they probably have +many more resources to throw at the problem. But with only 50 keysafe +users, recombining shards and trying super-weak passwords would be +prohibitively expensive as detailed above. So, a state-level entity +will probably only find it feasible to target particular people. +Since such an attack can be performed by anyone as discussed above, +there seems to actually be no incentive for a state-level to subpoena data. + +A state-level entity's best bet at getting lots of keys is probably to use +their resources to compromise keysafe servers, and modify them to log data. +Then a correlation attack can be done as discussed above. + +A different kind of attack: Legal/extralegal action to get a +particular person's key removed from storage servers to try to +deny them access to it. Or, to entirely take down storage servers. + +### Malicious data attack + +Two servers could collude to serve up malicious data to try to exploit the +user's system. + +For example, if the user is using their gpg key to encrypt emails, +and they restore a different gpg key, they might use it to encrypt with and +then what they said could be decrypted by the attacker. + +To perform this attack, the attacker first has to manage to crack the user's +password. Then they can replace the objects with malicious versions, encrypted +with the same password. + +So, this is not too useful for gpg key replacement, since the attacker +must already know the secret key. However, perhaps they could exploit bugs +in gpg to compromise the user's system. + +## Server list + +There's a server list shipped with the client, giving their tor onion address +and the organization providing the server. + +Three of the servers in the list are recommended servers. +Shards are stored on these unless overridden by other configuration. + +When recovering a key, the client tries the recommended servers first. But, +if it fails to recover the key using those, it goes on to try other servers +on the list. This way we don't need to remember which servers the shards +were stored on, and can change the recommended servers when necessary. + +See [[servers]] for more on the server list. + +## Servers + +Servers run exclusively as tor hidden services. This prevents them from +finding out the IP addresses of clients, as well as providing transport +level encryption. + +Servers should avoid keeping any logs, and should santize +the timestamps of any files stored on them. (Eg set back to epoch +and store on filesystem mounted with noatime.) + +Only small objects are accepted to be stored. This is to prevent this from +being used as a general purpose data storage system, and only be useful +for storing keys. + +However, `gpg --export-secret-key` can be hundreds of KB in size +when a key has a lot of signatures etc. While this size can be cut +down to 4 KB using `paperkey` to only include the secret key, it's +desirable to store the public and secret key together. This way, +a user does not have to publish the key to keyservers, which makes some +attack methods much less likely to try to crack their key. + +So, the object size should be at least a few tens of KB. 64kb seems +reasonable. If keysafe needs to store a larger key, it can chunk it up. + +Objects shoud be padded to a fixed size before they are encrypted, to +prevent attackers from correlating and targeting particular objects based +on size. + +## client-server Proof of Work + +The Proof of Work prevents servers being flooded with requests. +This is particularly important to prevent misuse of keysafe servers +to store large data on them. It's also somewhat useful to prevent attackers +guessing the name someone used to store a key; but the cost of generating +N from a name makes the server's proof of work only a secondary line of +defense against such an attack. Finally, PoW is useful to protect against +DOS attacks. + +Assuming that the client communicates with the server over http: + + PUT /keysafe/objects/N + GET /keysafe/objects/N + +The server's response can be either the result of the request, +or a proof of work requirement, which specifies the difficulty D +(number of 0's needed), random salt RS, and the number of argon2 +iterations. The client provides the proof of work in a query parameter, +which is a string S such that argon2(N,S+RS) starts with a given number +of 0's. + +(The server should only be able to control the number of iterations, +not other argon2 parameters, to avoid forcing the client to use too much +memory. Normally, the server will keep iterations small, probably 1, +since it does need to calculate the argon2 hash once itself.) + +The server can use a [token bucket](https://en.wikipedia.org/wiki/Token_bucket) +to throttle requests to a given rate. In fact, there can be a whole +series of token buckets B0,B1.., for increasing difficulty proofs of work. + +A request without a proof of work is checked in B0. If that bucket is empty, +the server responds with a proof of work requirement D=1, and +the client makes a new request whose proof of work allows access to B1. +If the server is under load, B1 might also be empty, and so the client +will have to try again with D=2 to access B2, and so on. + +If there are 4 buckets, and each bucket refills at the rate of a +token every minute, then the maximum allowed throughput is 4 requests +per minute. If calculating the proof of work takes 2^D seconds on average, +then it will take on average 16 minutes work to access B4. + +The server can generate a different RS for each request, and can +insert them into a bloom filter to keep track of ones it has given out. +Bloom filter false positives are not a problem because they are quite +rare and so it is not efficient for a client to make up RS in hope that +there will be a false positive. + +To guard against DOS attacks that reuse proofs of work, the server can +maintain a second bloom filter, putting RS into it once it's used, and +rejecting attempts that reuse a RS. Since the bloom filter will +(with a low probability) yield a false positive, the server should reject +an attempt by generating a new RS' and requesting a new proof of work from +the client. + +## Avoiding correlations + +As noted above, the more objects that are stored, the more secure +keysafe becomes, because it becomes harder to correlate objects +that belong to a user. + +Ways the server could draw correlations include: + +* Time that the data was stored. + (Avoid by waiting some period of time between uploading + various objects, probably on the order of days. If every keysafe uploads + its objects at midnight GMT, the server will find it hard to correlate + them.) +* IP address used to store the data. + (Using tor avoids this.) +* When the data was retrieved. + (Avoid by waiting some period of time between retrieving shards. + Although, this makes key recovery take longer, which could be + frustrating..) +* A user ID associated with the data. + (Avoid by allowing anyone to store data and don't associate data with + any user ID.) +* Same sized objects may be related shares. + (Avoid by making all objects stored be a standard size.) + +## Detecting corrupt data + + ori> if a single server is compromised, it can return bogus data when you request its fragment of the shared secret + ori> if you only have three servers, you can't know which two to trust, short of just trying + ori> you end up with three possible ways to reconstruct the secrets, A-B, A-C, B-C. only one is legit. + +This could also happen due to error not compromise. Or even due to +asking the wrong server for an object and getting back a dummy response. + +To guard against this, include a sha256sum of the secret key in the +data that is sharded. This way the validity of the restored key can be +verified. + +Note that this may make it marginally easier for brute force attacks, since +they can use that checksum to detect when the attack is successful. Only +marginally easier because it's not hard to fingerprint a gpg secret key. +Even the minimised raw key output by paperkey can be recognised by a parser. + +## Versioning + +The algorithms and parameters chosen by keysafe could turn out to be +wrong, or need adjusting to keep up with technology. While we'd like to +avoid this by getting the design right, it's important to have a plan in +case it becomes necessary. + +The simplest approach would be to include a version number with each shard. +But, this causes a problem: When switching to a new version, the early +atopters of that version are a small group, and so it becomes easier to +correlate their shards. + +The version number could instead be included in the data that is sharded. +This avoids the above problem, but leads to an even worse problem: +An attacker can look for the version number after combining some random +shards, and if they see it, they know they picked shards that are actually +related. As described in "Attack methods", if an attacker can do that, +it becomes easy for two colliding servers to find the right combinations of +all shards. + +A safe alternative to embedding a version number anywhere in the data is +to adjust the parameters of the argon2 hash used to generate the shard +names. Maintain a list of versions and their shard name argon2 +parameters (as well as other parameters etc). During key recovery, +keysafe can try different versions in turn, use argon2 to generate the +shard names, and see if those shards can be downloaded. Once it finds +shards, it knows the version that created them, and the other parameters +of how the data is encoded. + +The only downside to this method is that each new version added to the list +makes recovering data from all older versions take 10 minutes longer, as +the argon2 hash has to be run an additional time. + +Note that the argon2 hash parameters to vary between versions should not be +merely the number of rounds, as that would allow an attacker to hash for +each version's number of rounds in one pass. Instead, vary the hash +memory parameter. + +## Ideas + +Some ideas for improvements to keysafe. + +### Assisted Password-based Key Derivation + +An idea from [Nigori](http://www.links.org/files/nigori/nigori-protocol-01.html#anchor15): + +If the user has an account at some server, the server can contribute part +of the data used to generate the key encryption key K. So not only is the +user's keysafe password needed for key recovery, but the user has to +authenticate to the server. As well as adding entropy to K, the server +can do rate limiting to prevent password guessing. + +Risks include: + +* The server becomes a target to be compromised. +* If the server goes down, the user loses the ability to recover their gpg + key from keysafe. + +### Entangled objects + +An idea from Anthony Towns: + +Two or more objects stored on a keysafe server can be entangled. +When one of them is requested, the server should delete the others. + +This could be used in several ways: + +* Keysafe could upload random objects entangled with a key's object, + and keep local records of the names of the random objects. Then if the + user wants to stop storing a key on keysafe servers, keysafe can request + the entangled objects to (hopefully) delete the real objects from the + server. +* Keysafe could pick or prompt for some tripwire names that an attacker + might try if they were looking for a user's data. Then an attacker + risks deleting the data stored on the server. Although this also has + DOS potential. +* The user could pick a real name and fake name and keysafe uploads + objects for both. If the user is being forced to give up their keysafe + name and password, they could provide the fake name, and if it were + used, their data would get deleted from the keysafe servers. diff --git a/doc/faq.mdwn b/doc/faq.mdwn new file mode 100644 index 0000000..4512be7 --- /dev/null +++ b/doc/faq.mdwn @@ -0,0 +1,88 @@ +[[!toc]] + +### How does keysafe compare with paperkey? + +Using paperkey to print out your gpg key and locking it in a safe is a great +solution to gpg key backup. It requires a printer, a safe, and typing in many +numbers to restore the key. It avoids all attack methods except physical +theft, raids, and compromised printers. Gold standard. + +Using keysafe is analagous to storing the paperkey printout in a safety +deposit box at a bank, and using a really really strong gpg passphrase. +Since we don't trust a single bank (server), we shred the printout and +evenly distribute the shreds among several banks. While the banks know the +safety deposit boxes belong to you and could put the shreds back together, +a keysafe server has very little identifying information to go on (it only +knows when you made the deposit). + +### I copy secring.gpg to dropbox to back it up. Why bother with keysafe? + +So, you rely on your gpg passphrase for security. + +Gpg uses between 1024 and 65011712 rounds of SHA-1 hashing of +the passphrase, with the default probably being 65536. +In 2012, a GPU could calculate 2 billion SHA-1 hashes per second, +so this is not much of an impediment to password cracking at all. + +Assuming 100 gpg passphrases can be tried per second, and gpg is +configured to use the maximum rounds (which it normally is NOT): + +* Strong passphrase (50 entropy): 21421231 GPU-years +* Weak passphrase (30 entropy): 10 GPU-years +* Super-weak passphrase (19 entropy): 2 GPU-days + +So this might be secure enough for some, but only with a really good +passphrase. Probably, most people who copy their secring.gpg to +the cloud have either a weakish passphrase, or have not tuned gpg to +use maximum SHA-1 rounds, or both. So, they can probably be cracked in +days to weeks. + +Compare these numbers with the cost to crack keysafe passwords +(explained in [[details]]): + +* Strong password (50 entropy): 53553077761 CPU-years +* Weak password (30 entropy): 51072 CPU-years +* Super-weak password (19 entropy): 25 CPU-years + +(Note that is a comparison between GPU years and CPU years; SHA-1 used by +gpg can easily be run fast on GPUs, while keysafe uses argon2 which is +designed to be GPU-resistent.) + +Big difference! Indeed, the design of gpg prevents a really expensive hash +being used to protect against passphrase cracking, because it would slow down +day-to-day use of gpg. Keysafe can make cracking the password much more +expensive because it's only used for backup and restore. + +### Is keysafe suitable for backing up bitcoin wallets? + +Not recommended. Use a brain wallet. + +Keysafe might be more secure than a paper wallet in some situations. +It's happened before that someone has stumbled over someone else's +list of electrum words among their papers. Using keysafe avoids such +scenarios. + +#### How is keysafe different from other systems for private key backup/sync? + +Here are some similar systems, and intial impressions (which may be +inaccurate; corrections welcomed): + +* [Whiteout](https://blog.whiteout.io/2014/07/07/secure-pgp-key-sync-a-proposal/) + uses a 24 letter code to encrypt the secret key. This has to be written + down to back it up. Since it is high-entropy (256 bits), the encryption + can be fast, and so it can be used to sync private keys between devices. +* [Nigori](http://www.links.org/files/nigori/nigori-protocol-01.html) + uses a password to encrypt and SSS to split the private key. + Its main protection against password guessing seems be to be + its "Assisted Password-based Key Derivation", where some separate server + that the user has an account at supplies part of the encryption key after + the user has authenticated at the server. This allows the server to + rate-limit logins and so avoid password cracking (except by the server). + (This idea is worth keysafe stealing!) +* [LEAP](https://leap.se/en/docs/tech/hard-problems#availability-problem)'s + [Soledad](https://leap.se/soledad) uses a large secret to encrypt + private keys. This can be stored in a recovery document in a recovery + database, which anyone can make requests from. To prevent attacks, + the recovery database delays responses, and a recovery code is needed + to access a document. The recovery code is a 16 character code that the + user has to write down. diff --git a/doc/index.mdwn b/doc/index.mdwn new file mode 100644 index 0000000..d96bf9c --- /dev/null +++ b/doc/index.mdwn @@ -0,0 +1,81 @@ +Keysafe securely backs up a gpg secret key or other short secret to the cloud. + +This is not intended for storing Debian Developer keys that yield root on +ten million systems. It's about making it possible for users to use gpg who +currently don't, and who would find it too hard to use `paperkey` to back +up and restore their key as they reinstall their laptop. + +Not yet ready for production use! Needs security review! +May run over your dog! Not suitable for bitcoin keys! + +## Screenshots + +See [[screenshots]]. (Keysafe can also run in text mode in a terminal.) + +## How it works, basically + +The secret key is encrypted using a password, and is split into three +shards, and each is uploaded to a server run by a different entity. Any two +of the shards are sufficient to recover the original key. So any one server +can go down and you can still recover the key. + +Keysafe checks your password strength (using the excellent but not perfect +[zxcvbn library](https://github.com/tsyrogit/zxcvbn-c)), +and shows an estimate of the cost to crack your password, +before backing up the key. + +[[screenshots/4.png]] +(Above is for the password "makesad spindle stick") + +Keysafe is designed so that it should take millions of dollars of computer +time to crack any fairly good password. (This is accomplished using +[Argon2](https://en.wikipedia.org/wiki/Argon2).) +With a truely good password, such as four random words, the cracking cost +should be many trillions of dollars. + +The password is the most important line of defense, but keysafe's design +also makes it hard for an attacker to even find your encrypted secret key. + +For a more in-depth explanation, and some analysis of different attack +vectors (and how keysafe thwarts them), see [[details]]. +Also, there's a [[FAQ]]. + +## News + +[[!inline pages="code/keysafe/news/* and !*/Discussion" show="3"]] + +## Git repository + +`git clone git://keysafe.branchable.com/ keysafe` + +All tags and commits in this repository are gpg signed, and you should +verify the signature before using it. + +## Installation + +You should first install Haskell's stack tool, the readline and argon2 +libraries, and zenity. For example, on a Debian system: + + sudo apt-get install haskell-stack libreadline-dev libargon2-0-dev zenity + +Then to build and install keysafe: + + stack install keysafe + +Note that there is a manpage, but stack doesn't install it yet. + +## Reporting bugs + +Email + +## Servers + +See [[servers]] for information on the keysafe servers. + +## License + +Keysafe is licensed under the terms of the AGPL 3+ + +## Thanks + +Thanks to Anthony Towns for his help with keysafe's design. diff --git a/doc/news/version_0.20160927.mdwn b/doc/news/version_0.20160927.mdwn new file mode 100644 index 0000000..1787aa5 --- /dev/null +++ b/doc/news/version_0.20160927.mdwn @@ -0,0 +1,20 @@ +keysafe 0.20160927 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Makefile: Avoid rebuilding on make install, so that sudo make install works. + * Added --chaff-max-delay option for slower chaffing. + * Fix embedded copy of Argon2 to not use Word64, fixing build on 32 bit + systems. + * Randomize the server list. + * Don't upload more than neededshares-1 shares to Alternate servers + without asking the user if they want to do this potentially dangerous + action. + * Added a second keysafe server to the server list. It's provided + by Marek Isalski at Faelix. Currently located in UK, but planned move + to CH. Currently at Alternate level until verification is complete. + * Server: --motd can be used to provide a Message Of The Day. + * Added --check-servers mode, which is useful both at the command line + to see what servers keysafe knows about, and as a cron job. + * Server: Round number of objects down to the nearest thousand, to avoid + leaking too much data about when objects are uploaded to servers. + * Filter out escape sequences and any other unusual characters when + writing all messages to the console."""]] \ No newline at end of file diff --git a/doc/news/version_0.20161006.mdwn b/doc/news/version_0.20161006.mdwn new file mode 100644 index 0000000..2758b34 --- /dev/null +++ b/doc/news/version_0.20161006.mdwn @@ -0,0 +1,10 @@ +keysafe 0.20161006 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * New --add-storage-directory and --add-server options, which can be used + to make keysafe backup/restore using additional locations. + * Removed --store-local option; use --add-storage-directory instead. + * Fix bugs with entry of gpg keyid in the keysafe.log. + * Fix bug in --autostart that caused the full gpg keyid to be + used to generate object names, which made restores would only work + when --gpgkeyid was specifid. + * Remove embedded copy of argon2 binding, depend on fixed version of package."""]] \ No newline at end of file diff --git a/doc/news/version_0.20161007.mdwn b/doc/news/version_0.20161007.mdwn new file mode 100644 index 0000000..a7e8468 --- /dev/null +++ b/doc/news/version_0.20161007.mdwn @@ -0,0 +1,9 @@ +keysafe 0.20161007 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Check if --store-local directory is writable. + * Removed dependency on crypto-random. + * Added a LSB init script, for non-systemd systems. + (It currently uses Debian's start-stop-daemon, so would need porting + for other distributions.) + * /etc/default/keysafe is read by both the systemd service file and the + init script, and contains configuration for the keysafe server."""]] \ No newline at end of file diff --git a/doc/news/version_0.20161022.mdwn b/doc/news/version_0.20161022.mdwn new file mode 100644 index 0000000..e54f26e --- /dev/null +++ b/doc/news/version_0.20161022.mdwn @@ -0,0 +1,12 @@ +keysafe 0.20161022 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * Add keywords to desktop file. + Thanks, Sean Whitton + * Fix use of .IP macro in manpage. + Thanks, Sean Whitton + * Fix some mispellings. + Thanks, Sean Whitton + * Makefile: Propagate LDFLAGS, CFLAGS, and CPPFLAGS through ghc. + * Makefile: Allow setting BUILDER=./Setup to build w/o cabal or stack. + * Makefile: Allow setting BUILDEROPTIONS=-j1 to avoid concurrent + build, which should make build reproducible."""]] \ No newline at end of file diff --git a/doc/news/version_0.20161107.mdwn b/doc/news/version_0.20161107.mdwn new file mode 100644 index 0000000..d98987e --- /dev/null +++ b/doc/news/version_0.20161107.mdwn @@ -0,0 +1,14 @@ +keysafe 0.20161107 released with [[!toggle text="these changes"]] +[[!toggleable text=""" + * The third keysafe server is now available, provided by Purism. + * Purism's keysafe server has been vetted to Recommended level! + * Change default for --port to 4242. + * Fix --check-server to not fail when the server has not had anything + stored on it yet. + * --upload-queued: Exit nonzero if unable to upload all queued objects. + * --autostart: If unable to upload all queued objects initially, + delay between 1 and 2 hours and try again. + * Better suggestion when user is having difficulty thinking of a strong + enough password. + * Defer requesting secret key from gpg until just before backup, so the + user knows why gpg is asking for this secret key to be backed up."""]] \ No newline at end of file diff --git a/doc/screenshots.mdwn b/doc/screenshots.mdwn new file mode 100644 index 0000000..3e35cf2 --- /dev/null +++ b/doc/screenshots.mdwn @@ -0,0 +1,14 @@ + +[[screenshots/1.png]] + +[[screenshots/2.png]] + +[[screenshots/3.png]] + +(Entered password was "makesad spindle stick") + +[[screenshots/4.png]] + +[[screenshots/5.png]] + +[[screenshots/6.png]] diff --git a/doc/screenshots/0.png b/doc/screenshots/0.png new file mode 100644 index 0000000..7cfe206 Binary files /dev/null and b/doc/screenshots/0.png differ diff --git a/doc/screenshots/1.png b/doc/screenshots/1.png new file mode 100644 index 0000000..7759d6a Binary files /dev/null and b/doc/screenshots/1.png differ diff --git a/doc/screenshots/2.png b/doc/screenshots/2.png new file mode 100644 index 0000000..becd319 Binary files /dev/null and b/doc/screenshots/2.png differ diff --git a/doc/screenshots/3.png b/doc/screenshots/3.png new file mode 100644 index 0000000..58d7523 Binary files /dev/null and b/doc/screenshots/3.png differ diff --git a/doc/screenshots/4.png b/doc/screenshots/4.png new file mode 100644 index 0000000..418844a Binary files /dev/null and b/doc/screenshots/4.png differ diff --git a/doc/screenshots/5.png b/doc/screenshots/5.png new file mode 100644 index 0000000..89e1a22 Binary files /dev/null and b/doc/screenshots/5.png differ diff --git a/doc/screenshots/6.png b/doc/screenshots/6.png new file mode 100644 index 0000000..d750141 Binary files /dev/null and b/doc/screenshots/6.png differ diff --git a/doc/screenshots/restore/1.png b/doc/screenshots/restore/1.png new file mode 100644 index 0000000..8fd1f43 Binary files /dev/null and b/doc/screenshots/restore/1.png differ diff --git a/doc/screenshots/restore/2.png b/doc/screenshots/restore/2.png new file mode 100644 index 0000000..e682486 Binary files /dev/null and b/doc/screenshots/restore/2.png differ diff --git a/doc/screenshots/restore/3.png b/doc/screenshots/restore/3.png new file mode 100644 index 0000000..7c7e5dc Binary files /dev/null and b/doc/screenshots/restore/3.png differ diff --git a/doc/screenshots/restore/4.png b/doc/screenshots/restore/4.png new file mode 100644 index 0000000..4d07070 Binary files /dev/null and b/doc/screenshots/restore/4.png differ diff --git a/doc/servers.mdwn b/doc/servers.mdwn new file mode 100644 index 0000000..3e82c7e --- /dev/null +++ b/doc/servers.mdwn @@ -0,0 +1,194 @@ +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 + +### Recommended + +#### hlmjmeth356s5ekm.onion + + -----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 , + 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----- + +### Alternate + +#### keysafe.joeyh.name + + -----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----- + + +#### thirdserver + + Provided by Marek Isalski at [Faelix](http://www.faelix.net/). + Currently located in UK, but planned move to CH. + Vetting to Recommended level in progress. + +## Detailed requirements + +### Alternate + +* 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. + +### Recommended + +* 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.branchable.com/ keysafe` +* 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 id@joeyh.name to get added to keysafe's server list. + +Here's a the [[code/propellor]] config for my own keysafe server: + +--[[Joey]] diff --git a/doc/todo.mdwn b/doc/todo.mdwn new file mode 100644 index 0000000..6fa6e18 --- /dev/null +++ b/doc/todo.mdwn @@ -0,0 +1,4 @@ +This is keysafe's todo list. Link items to [[todo/done]] when done. + +[[!inline pages="./todo/* and !./todo/done and !link(done) +and !*/Discussion" actions=yes postform=yes show=0 archive=yes]] -- cgit v1.2.3