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 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