1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
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.
|
