Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some observations / possible optimisation #7

Open
caronni opened this issue Jul 11, 2019 · 1 comment
Open

Some observations / possible optimisation #7

caronni opened this issue Jul 11, 2019 · 1 comment

Comments

@caronni
Copy link

caronni commented Jul 11, 2019

Thank you for this nice implementation of SSS!

I'd like to bring a few issues to your attention:

  1. 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?

  2. 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.

  3. 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 :-)

  4. 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

@cipherboy
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants