shea256 / secret-sharing Goto Github PK
View Code? Open in Web Editor NEWA system for securely splitting secrets with Shamir's Secret Sharing Scheme
License: MIT License
A system for securely splitting secrets with Shamir's Secret Sharing Scheme
License: MIT License
Please redeploy as 0.2.7, thanks
Instead of drawing entropy automatically, is there an interface to input the random values?
What are the range of random values required?
Thank you.
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
It points to old repository.
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
def init(self, secret_int):
~~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
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.
This package doesn't support python 3 due to usage of "long"
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."
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?
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
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
Hi Ryan,
I ran the examples, it seems to hang at the entropy part.
Thank you.
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']
Hai,
is it possbile to have secrets longer than 500 chars (plaintext?)
Thx and greetings,
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
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?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.