summaryrefslogtreecommitdiffhomepage
path: root/doc/faq.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'doc/faq.mdwn')
-rw-r--r--doc/faq.mdwn88
1 files changed, 88 insertions, 0 deletions
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.