summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2017-04-04 12:48:13 -0400
committerJoey Hess <joeyh@joeyh.name>2017-04-04 12:48:13 -0400
commit1a1d0e95b8da5e67fb76589eecf72aa7592d7dd7 (patch)
treea3bb9f3f207c63f8709304125a5f5617bb964a8c
parent0d52ac5404f4203f5ea8dc13b5dcc30d67eaf444 (diff)
downloadkeysafe-1a1d0e95b8da5e67fb76589eecf72aa7592d7dd7.tar.gz
move TODO to doc/todo, expand a few items
-rw-r--r--Storage.hs3
-rw-r--r--TODO71
-rw-r--r--doc/todo/add_--key-value_option.mdwn5
-rw-r--r--doc/todo/custom_gui.mdwn10
-rw-r--r--doc/todo/delay_some_uploads_to_prevent_correlation.mdwn19
-rw-r--r--doc/todo/detect_bad_password_on_restore_and_re-prompt.mdwn2
-rw-r--r--doc/todo/future_encryption_tunables_changes.mdwn18
-rw-r--r--doc/todo/improve_restore_progress_bar.mdwn1
-rw-r--r--doc/todo/need_one_more_recommended_server.mdwn8
-rw-r--r--doc/todo/padding_to_prevent_traffic_analysis.mdwn3
-rw-r--r--doc/todo/remove_gpg_key_passphrase_from_backed_up_gpg_keys.mdwn17
-rw-r--r--doc/todo/remove_jargon.mdwn4
-rw-r--r--doc/todo/set_up_--check-servers_in_cron_job.mdwna3
-rw-r--r--doc/todo/usability_testing.mdwn3
-rw-r--r--doc/todo/use_locked_memory.mdwn5
-rw-r--r--keysafe.cabal1
16 files changed, 98 insertions, 75 deletions
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