From 99a5321aab580b2caa62559d3b6c016ccf15eb70 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 11 Mar 2017 11:34:46 -0400 Subject: idea from Thomas S --- TODO | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'TODO') diff --git a/TODO b/TODO index 7b56c90..5ddc006 100644 --- a/TODO +++ b/TODO @@ -98,3 +98,13 @@ Encryption tunables changes: 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. +* Thomas S points out that All-Or-Nothing Transform could be used to + prevent recovery of a partial key, when not all chunks are available to + an attacker. https://en.wikipedia.org/wiki/All-or-nothing_transform + For this to add security, there would need to be enough storage locations + that they can be partitioned into at least three sets, with the chunks split + amoung the three. One chunk probably contains the actual private + key material, a second signatures and other cruft, and the last chunk + would contain the AONT key. This would require all three sets of servers + to combine their material to crack the key. It would then make sense to + chunk even small keys. -- cgit v1.2.3 From f06692d75041bd646539eb79f4809666038d8f5b Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Sat, 11 Mar 2017 11:49:03 -0400 Subject: remove AONT If there are 3 chunks each split into 3 shares and distributed amoung 9 servers, and 2 shares are needed to recover each chunk, then with AONT, 6 servers need to collude to do so. Without AONT, a single chunk might contain the actual gpg private key, and only 3 servers might need to collude to recover that single chunk. On the other hand, with 9 servers, SSS can split the data into 9 shares with 6 needed for recovery. Thus, 6 servers will be needed to recover any data at all, no matter how it's chunked or which chunks contain the actual gpg key. So, I think that tuning SSS can provide the same effects as AONT. --- TODO | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'TODO') diff --git a/TODO b/TODO index 5ddc006..7b56c90 100644 --- a/TODO +++ b/TODO @@ -98,13 +98,3 @@ Encryption tunables changes: 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. -* Thomas S points out that All-Or-Nothing Transform could be used to - prevent recovery of a partial key, when not all chunks are available to - an attacker. https://en.wikipedia.org/wiki/All-or-nothing_transform - For this to add security, there would need to be enough storage locations - that they can be partitioned into at least three sets, with the chunks split - amoung the three. One chunk probably contains the actual private - key material, a second signatures and other cruft, and the last chunk - would contain the AONT key. This would require all three sets of servers - to combine their material to crack the key. It would then make sense to - chunk even small keys. -- cgit v1.2.3 From 0d52ac5404f4203f5ea8dc13b5dcc30d67eaf444 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Tue, 4 Apr 2017 12:30:13 -0400 Subject: move item from TODO to doc/todo and reply --- TODO | 29 ------------------ doc/todo.mdwn | 3 +- ...ent_1_4416f7495e2a34a3cdb6f5106beaf582._comment | 20 +++++++++++++ ...etect_number_of_required_shares_on_restore.mdwn | 34 ++++++++++++++++++++++ 4 files changed, 56 insertions(+), 30 deletions(-) create mode 100644 doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment create mode 100644 doc/todo/detect_number_of_required_shares_on_restore.mdwn (limited to 'TODO') diff --git a/TODO b/TODO index 7b56c90..83f153b 100644 --- a/TODO +++ b/TODO @@ -52,35 +52,6 @@ Wishlist: (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: diff --git a/doc/todo.mdwn b/doc/todo.mdwn index 6fa6e18..cb54209 100644 --- a/doc/todo.mdwn +++ b/doc/todo.mdwn @@ -1,4 +1,5 @@ -This is keysafe's todo list. Link items to [[todo/done]] when done. +This is keysafe's todo list. Please feel free to post ideas here. +Link items to [[todo/done]] when done. [[!inline pages="./todo/* and !./todo/done and !link(done) and !*/Discussion" actions=yes postform=yes show=0 archive=yes]] diff --git a/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment b/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment new file mode 100644 index 0000000..1a2871f --- /dev/null +++ b/doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment @@ -0,0 +1,20 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2017-04-04T16:19:10Z" + content=""" +You can use --totalshares and --neededshares to configure how many shares +keysafe splits the key into. See also +[[detect_number_of_required_shares_on_restore]]. + +Bear in mind that colluding servers still have to guess the name used to +find the shares to combine, and even then they still have the expensive +work of cracking the password ahead. Splitting the secret across servers is +only an initial line of defense. + +It's debatable whether having a lot of servers would add much security. + +But, keysafe needs more servers in any case. With more than 3 servers, +splits like 3-of-4 and 2-of-4 become usable; these and other parameters are +probably useful in some cases. +"""]] diff --git a/doc/todo/detect_number_of_required_shares_on_restore.mdwn b/doc/todo/detect_number_of_required_shares_on_restore.mdwn new file mode 100644 index 0000000..4bfa080 --- /dev/null +++ b/doc/todo/detect_number_of_required_shares_on_restore.mdwn @@ -0,0 +1,34 @@ +When --totalshares and --neededshares were used to back up a key, +those options (well at least --neededshares) +also have to be provided at restore time to make it try to find +enough shares to restore. + +It would be good to detect the number of required shares so the user does +not need to remember to do that. + +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. + +Problem with this: 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. -- cgit v1.2.3 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 (limited to 'TODO') 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