From eeda326eb9aa34ff325bc9d2d97f5cb42f3958b5 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 6 Oct 2016 15:00:14 -0400 Subject: update --- TODO | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) (limited to 'TODO') 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. -- cgit v1.2.3