You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Your choice of prime excludes 189 secret values in the range (0..2^256-1). Now, chances are tiny that any slice of s is >= your prime, but how about checking, or slicing by p, instead of 2^256, just in case?
What if my random secret just happens to have trailing zeros? Would those not be lost in mergeIntToByte()? I guess that warrants at least a documentation, or maybe encoding the length of the secret in some form.
Thank you for not reusing the polynomial coefficients a_1 .. a_{k-1} across the different pieces of large secrets. That would have ruined the day :-)
Suggestion: In the literature, people use x=1..n without adverse effects. This would almost halve the size of your output.
Putting these points up for discussion here. Do you think they are valid, and might warrant a code change?
Germano
The text was updated successfully, but these errors were encountered:
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.
(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 :)
Yes, we should really use a real padding scheme. You could definitely encode 4-bytes of length if you wanted to.
Mhmm, we at least tried to do that correctly. :)
(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.
Thank you for this nice implementation of SSS!
I'd like to bring a few issues to your attention:
Your choice of prime excludes 189 secret values in the range (0..2^256-1). Now, chances are tiny that any slice of s is >= your prime, but how about checking, or slicing by p, instead of 2^256, just in case?
What if my random secret just happens to have trailing zeros? Would those not be lost in mergeIntToByte()? I guess that warrants at least a documentation, or maybe encoding the length of the secret in some form.
Thank you for not reusing the polynomial coefficients a_1 .. a_{k-1} across the different pieces of large secrets. That would have ruined the day :-)
Suggestion: In the literature, people use x=1..n without adverse effects. This would almost halve the size of your output.
Putting these points up for discussion here. Do you think they are valid, and might warrant a code change?
Germano
The text was updated successfully, but these errors were encountered: