move TODO to doc/todo, expand a few items

13 files changed, 98 insertions, 0 deletions

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]].
+