diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 54 |
1 files changed, 54 insertions, 0 deletions
@@ -0,0 +1,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. |