summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2017-04-04 12:30:13 -0400
committerJoey Hess <joeyh@joeyh.name>2017-04-04 12:30:13 -0400
commit0d52ac5404f4203f5ea8dc13b5dcc30d67eaf444 (patch)
tree71b5005ba88390f733325bc17c77574ff9e009ae
parent97739621230f267ac783bd3d9902eff8cee2ad27 (diff)
downloadkeysafe-0d52ac5404f4203f5ea8dc13b5dcc30d67eaf444.tar.gz
move item from TODO to doc/todo and reply
-rw-r--r--TODO29
-rw-r--r--doc/todo.mdwn3
-rw-r--r--doc/todo/Make_the_number_of_shard_servers_configurable/comment_1_4416f7495e2a34a3cdb6f5106beaf582._comment20
-rw-r--r--doc/todo/detect_number_of_required_shares_on_restore.mdwn34
4 files changed, 56 insertions, 30 deletions
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.