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
|
Soon:
* Get some keysafe servers set up.
* Set up --check-servers in a cron job, so I know when servers are down.
Later:
* The attack cost display can lead to a false sense of security if the user
takes it as gospel. It needs to be clear that it's an estimate. This and
other parts of the keysafe UI need usability testing.
* 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.
* --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.
* In backup, only upload to N-1 servers immediately, and delay the rest
for up to several days, with some uploads of chaff, to prevent
collaborating evil servers from correlating related shards.
* Add some random padding to http requests and responses, to make it
harder for traffic analysis to tell that given TOR traffic is
keysafe traffic.
* Argon2d is more resistent to GPU/ASIC attack optimisation.
Switching from Argon2i would require new tunables, so deferred for now
until there's some other reason to change the tunables.
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..
* Don't require --totalshares and --neededshares on restore when unusual
values were used for backup.
The difficulty is that the number of needed shares cannot be determined by
looking at shares, and guessing it wrong will result in combining
too few shares yielding garbage, which it will take up to an hour to
try to decrypt, before it can tell that more shares are needed.
This could be dealt with by including the number of needed shares in the
serialization of Share, but then an attacker could use it to partition
shares from servers. If only one person uses --neededshares=5,
the attacker can guess that all their shares go together.
What about including the number of needed shares in the name? Since that's
hashed, it's not visible to an attacker. Keysafe would need to try names
with 2 shares, then 3, etc, and once it found shares, it would know the
number needed. It should also be possible to avoid breaking backwards
compatability, by only including the number of shares in the name when
it's not the standard number.
|
