summaryrefslogtreecommitdiffhomepage
diff options
context:
space:
mode:
authorJoey Hess <joeyh@joeyh.name>2016-10-06 17:28:53 -0400
committerJoey Hess <joeyh@joeyh.name>2016-10-06 17:28:53 -0400
commit4e1f16e4001722603c231dddebc631988fdb8d34 (patch)
tree5fa6e9f573509012354d227b21c76323b4fbce71
parent9d71858c598e6ccaf260fef3d1e90c1e3ea44775 (diff)
downloadkeysafe-4e1f16e4001722603c231dddebc631988fdb8d34.tar.gz
thought
-rw-r--r--TODO9
1 files changed, 9 insertions, 0 deletions
diff --git a/TODO b/TODO
index 3d4ff54..17f7cb9 100644
--- a/TODO
+++ b/TODO
@@ -32,11 +32,20 @@ Wishlist:
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.