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