From 1a1d0e95b8da5e67fb76589eecf72aa7592d7dd7 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 4 Apr 2017 12:48:13 -0400 Subject: move TODO to doc/todo, expand a few items --- Storage.hs | 3 - TODO | 71 ---------------------- doc/todo/add_--key-value_option.mdwn | 5 ++ doc/todo/custom_gui.mdwn | 10 +++ .../delay_some_uploads_to_prevent_correlation.mdwn | 19 ++++++ ...tect_bad_password_on_restore_and_re-prompt.mdwn | 2 + doc/todo/future_encryption_tunables_changes.mdwn | 18 ++++++ doc/todo/improve_restore_progress_bar.mdwn | 1 + doc/todo/need_one_more_recommended_server.mdwn | 8 +++ doc/todo/padding_to_prevent_traffic_analysis.mdwn | 3 + ...gpg_key_passphrase_from_backed_up_gpg_keys.mdwn | 17 ++++++ doc/todo/remove_jargon.mdwn | 4 ++ doc/todo/set_up_--check-servers_in_cron_job.mdwna | 3 + doc/todo/usability_testing.mdwn | 3 + doc/todo/use_locked_memory.mdwn | 5 ++ keysafe.cabal | 1 - 16 files changed, 98 insertions(+), 75 deletions(-) delete mode 100644 TODO create mode 100644 doc/todo/add_--key-value_option.mdwn create mode 100644 doc/todo/custom_gui.mdwn create mode 100644 doc/todo/delay_some_uploads_to_prevent_correlation.mdwn create mode 100644 doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn create mode 100644 doc/todo/future_encryption_tunables_changes.mdwn create mode 100644 doc/todo/improve_restore_progress_bar.mdwn create mode 100644 doc/todo/need_one_more_recommended_server.mdwn create mode 100644 doc/todo/padding_to_prevent_traffic_analysis.mdwn create mode 100644 doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn create mode 100644 doc/todo/remove_jargon.mdwn create mode 100644 doc/todo/set_up_--check-servers_in_cron_job.mdwna create mode 100644 doc/todo/usability_testing.mdwn create mode 100644 doc/todo/use_locked_memory.mdwn diff --git a/Storage.hs b/Storage.hs index feb5791..88e6ae5 100644 --- a/Storage.hs +++ b/Storage.hs @@ -73,9 +73,6 @@ problemStoringIn (StorageLocations locs) tunables -- -- If a server is not currently accessible, it will be queued locally. -- If any uploads are queued, returns True. --- --- TODO: Add shuffling and queueing/chaffing to prevent --- correlation of related shares. storeShares :: StorageLocations -> ShareIdents -> [S.Set Share] -> UpdateProgress -> IO (StoreResult, Bool, [Storage]) storeShares (StorageLocations locs) allsis shares updateprogress = do ((r, anyqueued), usedlocs) <- go allsis shares [] False diff --git a/TODO b/TODO deleted file mode 100644 index 83f153b..0000000 --- a/TODO +++ /dev/null @@ -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. diff --git a/doc/todo/add_--key-value_option.mdwn b/doc/todo/add_--key-value_option.mdwn new file mode 100644 index 0000000..bd6e918 --- /dev/null +++ b/doc/todo/add_--key-value_option.mdwn @@ -0,0 +1,5 @@ +--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. + diff --git a/doc/todo/custom_gui.mdwn b/doc/todo/custom_gui.mdwn new file mode 100644 index 0000000..c2863f6 --- /dev/null +++ b/doc/todo/custom_gui.mdwn @@ -0,0 +1,10 @@ +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. +* Make --gui password entry fields longer, so user does not feel they + need to make password short. (zenity does not seem to allow configuring + this.) diff --git a/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn b/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn new file mode 100644 index 0000000..5b9e324 --- /dev/null +++ b/doc/todo/delay_some_uploads_to_prevent_correlation.mdwn @@ -0,0 +1,19 @@ +In backup, only upload to some 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. + +How many servers should be uploaded to immediately? The safe answer is at least +M (--neededshares); that way the secret key does get backed up immediately. + +Uploading to less would be more secure, but risks the user thinking it +finished backing up the key, and eg, wiping their laptop. So careful +messaging would be needed in this case. + +Might just upload M-1 shares immediatly, and show a dialog saying, the +backup will be completed next Wednesday, or click here to finish it now. + +---- + +Also, when there are multiple chunks, they are currently uploaded in order. +That could easily be shuffled, with server A getting its share of chunk 2 +first, server B its share of chunk 3 first, etc. diff --git a/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn b/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn new file mode 100644 index 0000000..f010676 --- /dev/null +++ b/doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn @@ -0,0 +1,2 @@ +If we retrieved enough shares successfully, but decrypt failed, must +be a wrong password, so prompt for re-entry and retry with those shares. diff --git a/doc/todo/future_encryption_tunables_changes.mdwn b/doc/todo/future_encryption_tunables_changes.mdwn new file mode 100644 index 0000000..8a9b29d --- /dev/null +++ b/doc/todo/future_encryption_tunables_changes.mdwn @@ -0,0 +1,18 @@ +If switching any of the encryption tunables for some reason, +consider making these changes all at once: + +* 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. +* Perhaps use CHACHA2 instead of AES? diff --git a/doc/todo/improve_restore_progress_bar.mdwn b/doc/todo/improve_restore_progress_bar.mdwn new file mode 100644 index 0000000..5a6af76 --- /dev/null +++ b/doc/todo/improve_restore_progress_bar.mdwn @@ -0,0 +1 @@ +improve restore progress bar points (update after every hash try) diff --git a/doc/todo/need_one_more_recommended_server.mdwn b/doc/todo/need_one_more_recommended_server.mdwn new file mode 100644 index 0000000..a699643 --- /dev/null +++ b/doc/todo/need_one_more_recommended_server.mdwn @@ -0,0 +1,8 @@ +There is currently only 1 recommended server; keysafe needs one more before +it can be used without warning that it's uploading 2 shares to +not-recommended servers. + +Probably need a new recommended server. The existing non-recommended +servers don't have warrant canaries for various reasons. + +[[!tag important]] diff --git a/doc/todo/padding_to_prevent_traffic_analysis.mdwn b/doc/todo/padding_to_prevent_traffic_analysis.mdwn new file mode 100644 index 0000000..c2aa3c1 --- /dev/null +++ b/doc/todo/padding_to_prevent_traffic_analysis.mdwn @@ -0,0 +1,3 @@ +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. diff --git a/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn b/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn new file mode 100644 index 0000000..5a370be --- /dev/null +++ b/doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn @@ -0,0 +1,17 @@ +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. diff --git a/doc/todo/remove_jargon.mdwn b/doc/todo/remove_jargon.mdwn new file mode 100644 index 0000000..8706010 --- /dev/null +++ b/doc/todo/remove_jargon.mdwn @@ -0,0 +1,4 @@ +Add --no-jargon which makes the UI avoid terms like "secret key" and "crack +password". Do usability testing! + +Should perhaps be default? diff --git a/doc/todo/set_up_--check-servers_in_cron_job.mdwna b/doc/todo/set_up_--check-servers_in_cron_job.mdwna new file mode 100644 index 0000000..311ae71 --- /dev/null +++ b/doc/todo/set_up_--check-servers_in_cron_job.mdwna @@ -0,0 +1,3 @@ +So I know when servers go down. --[[Joey]] + +[[!tag important]] diff --git a/doc/todo/usability_testing.mdwn b/doc/todo/usability_testing.mdwn new file mode 100644 index 0000000..de8e801 --- /dev/null +++ b/doc/todo/usability_testing.mdwn @@ -0,0 +1,3 @@ +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. Is it? +This and other parts of the keysafe UI need usability testing. diff --git a/doc/todo/use_locked_memory.mdwn b/doc/todo/use_locked_memory.mdwn new file mode 100644 index 0000000..2d139a3 --- /dev/null +++ b/doc/todo/use_locked_memory.mdwn @@ -0,0 +1,5 @@ +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.. But, see [[remove_gpg_key_passphrase_from_backed_up_gpg_keys]]. + diff --git a/keysafe.cabal b/keysafe.cabal index 42e95fd..99330e4 100644 --- a/keysafe.cabal +++ b/keysafe.cabal @@ -19,7 +19,6 @@ Description: License-File: AGPL Extra-Source-Files: CHANGELOG - TODO INSTALL keysafe.1 keysafe.service -- cgit v1.2.3