diff options
Diffstat (limited to 'TODO')
-rw-r--r-- | TODO | 74 |
1 files changed, 74 insertions, 0 deletions
@@ -0,0 +1,74 @@ +Soon: + +* Finish vetting 2 servers to Recommended. +* 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. +* Make --gui password entry fields longer, so user does not feel they need + to make password short. (zenity may not allow configuring this) +* 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, and delay restores + (of keys backed up using the old tunables, and when the user provides the + wrong name) by ~10 minutes, so deferred for now + until there's some other reason to change the tunables. + +Wishlist: + +* Custom GUI, instead of zenity. Allows: + - Fewer screens by consolidating multiple prompts. + - Check same password entered second time and don't allow continuing + if not. + - Password strengh display, and don't allow continuing if password is too + weak. +* 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. To avoid needing to re-run argon2 for each + try, the argon2 hash of the name could be calculated first, and then the + number of needed shares appended before the final sha256 hash is + generated. + + If an attacker is able to guess the name, and a nonstandard number of + shares was used, the attacker could upload other objects where they would + be found before the real objects. This could be used to prevent + restore from working. (It also makes a malicious data attack (as described + in https://keysafe.branchable.com/details/) possible by attackers who do not + control the servers. |