Removing CommittedDeRecshare per agreement 2023-12-05, adding note as…

[jorabin]

… to where to find it.

[lbaird]

It looks like this is removing the protobuf for one algorithm (number 0), and adding a protobuf for a different algorithm (number 1). The intent seems to be that it is suggested that both algorithms be supported by apps.

If there are going to be 2 suggested algorithms, then they should be in the same repo. It doesn't make sense to split them across two different repos.

This new algorithm 1 requires exponential amounts of calculations for recovery in the presence of malicious helpers. That's an attack vector that we may want to avoid. Algorithm 0 is the same as 1, except it prevents that attack.

[jorabin]

There is a misunderstanding going on here. Not least that the comment that says "algorithm 1" is a typo and should say algorithm 0.

At present StoreShareRequest contains CommittedDeRecShare which in turn contains Secret.

What is proposed is that StoreShareRequest contains a byteString which in algoritm 0 is a CommittedDeRecShare. CommittedDerecShare is specified in cryptography. Cryptography implements DeRecShareProvider and wraps the byte[] provided as a CommittedDeRecShare.

The api using the ShareProvider needs to structure the data it passes in the byte[] as a Share to include the secret and its associated metadata. Hence the provision of Secret as a stand-alone protobuf.

As things stand, there are no changes proposed to either CommittedDerecShare or to Secret, however, Secret doesn't appear to contain (and has never contained) necessary metadata, and will need to change.

I'm not clear why you say that algorithm 1 requires exponential amounts of calculation since as noted it's exactly the same as algorithm 0 apart from the typo noted above.