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.