Consider providing a low-level crate without protobuf

[kpcyrd]

Hello!

I've noticed there are very few crates implementing shamir's secret sharing scheme and RustySecrets seems to be the most advanced (and the only one that is still maintained, sadly).

I've noticed there are issues with protobuf (#69 and the current protobuf dependency is outdated) and since I had trouble with protobuf+rust myself in the past I'm feeling a bit uncomfortable about that.

I'm very interested in the ssss code itself though and considering to use it in a project. I would probably solve the signature problem myself by specifying a binary format and write a nom parser manually, and possibly drop K and N from the shares-string and store that information somewhere else in the application.

If there's interest I could also prepare a patch to replace protobuf in RustySecrets, but this is probably not what you want since that would be a breaking change.

The reason why a separate crate might be a good idea is because even if protobuf would be changed to an optional dependency, this still needs to be handled when packaging the crate for debian. This is a bit far ahead, but something I started paying attention to recently.

Please let me know if you have any thoughts about that :)

[psivesely]

I, for one, would like to see a version of this package that breaks its dependency on protobuf, but there are some very large changes being worked on for this repository at the moment, and can't say if a PR for this would be accepted in the near term. Additionally, I didn't choose to hardcode protobuf myself, and there may be a reason for that, but we'll have to see if an earlier author can comment to that regard.