1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
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.
|
