diff options
Diffstat (limited to 'TODO')
| -rw-r--r-- | TODO | 71 |
1 files changed, 0 insertions, 71 deletions
@@ -1,71 +0,0 @@ -Soon: - -* Finish vetting 2 servers to Recommended. -* Set up --check-servers in a cron job, so I know when servers are down. -* Remove gpg key passohrase from gpg keys that keysafe backs up. - The reason for this is that the user may well forget their gpg key - passphrase, and it's *weird* to restore a key with keysafe's password - and then have it passphrase protected. - The gpg key passphrase is intended only to keep a key from being used - for a short period of time (a week or so) when the device holding it - is known to have been compromised, so the key can be revoked. - This doesn't really apply to keys backed up with keysafe -- if they get - compromised somehow, the user won't know, and cracking the gpg passphrase - should be almost trivial to an attacker who was able to break keysafe's - password. - paperkey can remove gpg key passphrases. Is there any better way? - It might make sense for keysafe to prompt for a new gpg passphrase - when restoring. - -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. - -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.. - -Encryption tunables changes: - -* 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. -* The ShareIdents derivation currently appends a number and sha256 hashes - to generate a stream of values. Ben M points out that HMAC is a more - typical way to do such a thing. Even better, a HKDF-Expand - (RFC5869) can generate a stream which can then be chunked up into values. - Either of these would avoid a full pre-image attack on SHA-2 breaking - keysafe. Of course, such an SHA-2 attack would be a general security - disaster. HKDF may prove more robust in the face of partial SHA-2 breaks. - Deferred for now until tthere's some other reason to change keysafe's - tunables. |