Hi Ryan,
I ran the examples, it seems to hang at the entropy part.

Thank you.

It points to old repository.

My original secret is 0ZOyJJ6q7Hc0f5f5C0XPTKZNgIc3g0QRi90fFGWa7qnws8LVUZ6sTYEFiyey3n+l and when I have it recovered, it becomes ZOyJJ6q7Hc0f5f5C0XPTKZNgIc3g0QRi90fFGWa7qnws8LVUZ6sTYEFiyey3n+l.

I use the PlaintextToHexSecretSharer exactly as described in README.md.

Would you, please, help me?

from secretsharing import PlaintextToHexSecretSharer as ssss
from secretsharing import SecretSharer
from secretsharing import base64_chars

I want to share Custom formats secrets, but Python3 told me
Traceback (most recent call last):
File "E:\python\exp.py", line 3, in <module>
from secretsharing import base64_chars
ImportError: cannot import name 'base64_chars'

Can u give me some suggestions?

Hai,

is it possbile to have secrets longer than 500 chars (plaintext?)

Thx and greetings,

So why are there only the smallest 257, 321 and 385 bit primes on the list?
And why does it not include 2^x-y and 2^(x-1)+y and 2^(x-1)-y on the list?

This is my own collection of primes
https://github.com/DonaldTsang/Personal/blob/master/shamir.py

This is what I get:

Traceback (most recent call last):
  File "/Users/Adam/PycharmProjects/SEVAS/local/key_management.py", line 5, in <module>
    from secretsharing import PlaintextToHexSecretSharer
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/secretsharing/__init__.py", line 12, in <module>
    from .sharing import *
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/secretsharing/sharing.py", line 14, in <module>
    from .primes import get_large_enough_prime
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/secretsharing/primes.py", line 35, in <module>
    STANDARD_PRIMES = calculate_mersenne_primes() + [
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/secretsharing/primes.py", line 25, in calculate_mersenne_primes
    prime = long(1)
NameError: name 'long' is not defined

It would be reassuring if one could recover secrets using the ssss utility. However, it doesn't appear to work:

from secretsharing import PlaintextToHexSecretSharer
>>> PlaintextToHexSecretSharer.split_secret("hello", 3, 5)
['1-231aa4dc', '2-3224bff9', '3-134b1e74', '4-468dc04c', '5-4beca582']

$ ssss-combine -t3 -n5
Enter 3 shares separated by newlines:
Share [1/3]: 3-134b1e74
Share [2/3]: 4-468dc04c
Share [3/3]: 5-4beca582
WARNING: security level too small for the diffusion layer.
Resulting secret: ....
WARNING: binary data detected, use -x mode instead.
$ ssss-combine -t3 -n5 -x
Enter 3 shares separated by newlines:
Share [1/3]: 5-4beca582
Share [2/3]: 4-468dc04c
Share [3/3]: 3-134b1e74
WARNING: security level too small for the diffusion layer.
Resulting secret: a313fced

It's unclear to me how a313fced (which I assume is a hex representation of binary data) can correspond to the string "hello."

I wanted to use the additively homomorphic property of the secret sharing, so I wrote a little toy program to generate two sets of shares from two secrets, add them and reconstruct the sum from the new summed shares. The reconstruction works correctly only some of the time though. There also seems to be some pattern to the incorrect reconstruction.

This is the program:

from secretsharing import secret_int_to_points, points_to_secret_int

secret1 = 5
shares1 = secret_int_to_points(secret1, 2, 3)
print(secret1)
print(shares1)

secret2 = 7
shares2 = secret_int_to_points(secret2, 2, 3)
print(secret2)
print(shares2)

secretsum = [ (x1, (y1+y2)) for ((x1,y1),(x2,y2)) in zip(shares1, shares2) ]
print(secretsum)

plainsum = points_to_secret_int(secretsum[0:2])
print(plainsum)

I appended some of the outputs, with rough estimates of how often they occur:

With the two secrets being 5 and 7 about ~20% of the time I get a correct result.

5
[(1, 4L), (2, 3L), (3, 2L)]
7
[(1, 6L), (2, 5L), (3, 4L)]
[(1, 10L), (2, 8L), (3, 6L)]
12

Maybe ~60% of the time I get output similar to this:

5
[(1, 1L), (2, 4L), (3, 0L)]
7
[(1, 0L), (2, 0L), (3, 0L)]
[(1, 1L), (2, 4L), (3, 0L)]
5

And the other ~20% these two have popped up so far.

5
[(1, 6L), (2, 0L), (3, 1L)]
7
[(1, 4L), (2, 1L), (3, 5L)]
[(1, 10L), (2, 1L), (3, 6L)]
19

5
[(1, 2L), (2, 6L), (3, 3L)]
7
[(1, 2L), (2, 4L), (3, 6L)]
[(1, 4L), (2, 10L), (3, 9L)]
29

With secrets 4 and 8, ~80% of the time I get a correct result.

4
[(1, 5L), (2, 6L), (3, 0L)]
8
[(1, 14L), (2, 20L), (3, 26L)]
[(1, 19L), (2, 26L), (3, 26L)]
12

And ~20% of the time I get this.

4
[(1, 0L), (2, 3L), (3, 6L)]
8
[(1, 22L), (2, 5L), (3, 19L)]
[(1, 22L), (2, 8L), (3, 25L)]
5

To reproduce:

>>> from secretsharing import SecretSharer
>>>
>>> secret = "04bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a"
>>> shares = SecretSharer.split_secret(secret, 2, 3)
>>> recovered = SecretSharer.recover_secret(shares[0:2])
>>> recovered == secret
False

This is due utilitybelt's charset_to_int behavior of dropping leading characters corresponding to a 0 in the charset when it is called on the secret.

If this is not the intended behavior from utilitybelt, a simple fix is to modify charset_to_int and int_to_charset to prepend a 1 to the returned value in order to preserve leading zeroes.

def init(self, secret_int):

This line is missing some parethesis. It should be

    ~~if not isinstance(secret_int, (int, long)) and secret_int >= 0:~~
    if not (isinstance(secret_int, (int, long)) and secret_int >= 0):
        raise ValueError("Secret must be a non-negative integer.")
    self._secret = secret_int

This package doesn't support python 3 due to usage of "long"

Instead of drawing entropy automatically, is there an interface to input the random values?
What are the range of random values required?

Thank you.

Hello,

I did a quick review inside the code, and found the following
exponentiation = (long(x)**i) % prime
at https://github.com/onenameio/secret-sharing/blob/master/secretsharing/polynomials.py#L52

I wonder if there is any reason not to use Python's built-in pow(x,y,z) which is, according to the documentation

compute more efficiently than pow(x, y) % z

I thought about timing-attack on pow() but cannot find anything on the internet

Depending on the secret, the shares have different length. Based on spec it should always be the same length as the original secret.

Correct length:

>>> SecretSharer.split_secret("205fcb5bd65d590c3b187a88bce077b9", 3, 5)
['1-26d92b6af22b9e72813806200d81f6d0', '2-6a71a977eeab9bb01a042934fd63299', '3-3fc998e17c9aaae5bc512fe283dd2b13', '4-5240a648eb3b71f2b14ace0da996e03f', '5-3e0c42cdcacd0ee1e08d1d14c103521d']

Longer than expected:

>>> SecretSharer.split_secret("c61b5432ae2436d8fc29ae38a205227c", 3, 5)
['1-63571f1a138698048c6cb5c743237939b0b1a021a5471a3c843eae8022a40db8', '2-66698be3fa70cdd2083df9367463f9c81193fadc6194c1494f264dc19b91d1ef', '3-937465db4bea1687373ca4d93c181abe8c26462e30d2bff5ce08bfd0cce6f21', '4-4bc04e87427012c7ce0e290ca13c10e5363cdcb529b05a5ead6d69327659e677', '5-2e04a460a38521f0180d15739cd3a773fa0363d3357e4c6740cce561d83436c8']

The secret_int_to_points function chooses a prime just greater than secret_int and num_points. The reverse function points_to_secret_int chooses a prime just greater than all the y coordinates in the shares.

Suppose the prime in the first case was 8191 (say secret_int was 5000). Its possible that the y coordinates of all points generated is less than 127. If this happens, then the prime number chosen by the points_to_secret_int function is 127 instead of 8191. Won't this lead to inconsistencies in the recovery of the original secret? Am I missing something here?

@tRavAsty @springlabs @covalent-hq @ml31415 and @kyokley are all active maintainers of their fork, is it possible to give them power over the repo?

Please redeploy as 0.2.7, thanks

I was looking at using this to split some secrets. However, I wanted to be able to use multiple programs to create and restore these.

When I used the values from the README with http://point-at-infinity.org/ssss/, I don't get the expected results. Is there anything to do to make these compatible?

$ ssss-combine -t 2
Enter 2 shares separated by newlines:
Share [1/2]: 1-58cbd30524507e7a198bdfeb69c8d87fd7d2c10e8d5408851404f7d258cbcea7
Share [2/2]: 2-ecdbdaea89d75f8e73bde77a46db821cd40f430d39a11c864e5a4868dcb403ed
Resulting secret: : ...y.;ch`J..]H...19..r.MV.....
WARNING: binary data detected, use -x mode instead.

$ ssss-combine -t 2 -x
Enter 2 shares separated by newlines:
Share [1/2]: 1-58cbd30524507e7a198bdfeb69c8d87fd7d2c10e8d5408851404f7d258cbcea7
Share [2/2]: 2-ecdbdaea89d75f8e73bde77a46db821cd40f430d39a11c864e5a4868dcb403ed
Resulting secret: 3a20ed1e8a79d63b6368604ae1b65d48a3be893139fdec72c14d56df9deca4df

The expected resulting secret is c4bbcb1fbec99d65bf59d85c8cb62ee2db963f0fe106f483d9afa73bd4e39a8a