blob: bc24016e58ae858c1cf20ff259a60c0dafb88ece (
plain)
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
|
Soon:
* Run a key restore and make sure it takes 35 to 50 minutes.
* client/server Proof Of Work
* Implement the different categories of servers in the server list.
* Include an example tor hidden service config
* Get some keysafe servers set up.
* Keep a local record of keys that have been backed up, and the tunables
and password entropy. This will allow warning later if the crack estimate
has to be revised downward for some reason, or if a server is
compromised.
* Run --uploadqueued periodically (systemd timer?)
Later:
* improve restore progress bar points (update after every hash try)
* If we retrieved enough shares successfully, but decrypt failed, must
be a wrong password, so prompt for re-entry and retry with those shares.
* Don't require --totalshares and --neededshares on restore when unusual
values were used for backup. Instead, probe until enough shares are found
to restore.
* --no-jargon which makes the UI avoid terms like "secret key" and "crack
password". Do usability testing!
* --key-value=$N which eliminates the question about password value,
and rejects passwords that would cost less than $N to crack at current
rates. This should add a combo box to the password entry form in the
GUI to let the user adjust the $N there.
* --name and --othername to allow specifying those at the command line,
bypassing the prompts. With these and --key-value, keysafe would only
prompt for the password.
Wishlist:
* Keep secret keys in locked memory until they're encrypted.
(Raaz makes this possible to do.)
Would be nice, but not super-important, since gpg secret keys
are passphrase protected anyway..
|