Some observations / possible optimisation about sssa-golang HOT 1 OPEN

Yeah, we're not actively working on this project any more. There's several other projects in this space like hashicorp vault that we'd probably use instead.

If you wanted to improve the libraries, feel free. I don't know if we should update all libraries to match (@Mab879 might have some opinions here), or if we're content with letting them be incompatible.

1. (iirc) We chose the first prime smaller than 2^256 so it would fit in a fixed 32 bytes each. You could slice by p, but that'd require a bit of work to rebuild the secret afterwards; IIRC this scheme lets you reconstruct bits of the secret if you wanted to, without rebuilding the entire secret. You could slice by 2^248 I suppose... We didn't really have a great solution to this and mostly chose to ignore this problem :)
2. Yes, we should really use a real padding scheme. You could definitely encode 4-bytes of length if you wanted to.
3. Mhmm, we at least tried to do that correctly. :)
4. (I haven't looked at the code in a long while); do you have a reference for this? I'm not immediately sure what you're talking about here.

from sssa-golang.