update

1 files changed, 10 insertions, 4 deletions

diff --git a/TODO b/TODO
index 44bbb00..3d4ff54 100644
--- a/TODO
+++ b/TODO
@@ -11,10 +11,6 @@ Later:
 * 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.
-* Don't require --totalshares and --neededshares on restore when unusual
-  values were used for backup. Instead, try to download at least 2 shares,
-  and run SS.decode. If it throws AssertionFailed, there were not enough
-  shares, so get more shares and retry.
 * --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,
@@ -34,3 +30,13 @@ 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.