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 --- ...etect_number_of_required_shares_on_restore.mdwn | 34 ++++++++++++++++++++++ 1 file changed, 34 insertions(+) create mode 100644 doc/todo/detect_number_of_required_shares_on_restore.mdwn (limited to 'doc/todo/detect_number_of_required_shares_on_restore.mdwn') 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