9 ms·

Show HN: 100% offline Shamir's Secret Sharing GUI

180 points by l1am0 6y ago

aprao 6y ago
This is really cool! Very small suggestion, I'd put Minimum required shares ahead of Shares so that it follows the m-of-n order.
- l1am0 6y ago
  Nice UX improvement. Will add it Edit: Added
deleted 6y ago
[deleted]
jaspax 6y ago
A very minor nit: Your placeholder text begins "What every message", where I'm pretty sure you meant "Whatever message". Initially confusing until I figured out what you meant.
- l1am0 6y ago
  Damn. This should not have happened. Thanks for that note:) Will change that asap Edit: Fixed together with other spelling mistakes
ISL 6y ago
I didn't know the algorithm: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing
- schoen 6y ago
  A fun fact is that this is one of only two algorithms in https://en.wikipedia.org/wiki/Category:Information-theoretically_secure_algorithms https://en.wikipedia.org/wiki/Category:Information-theoretic... The idea is that there is no amount of computational capacity or mathematical insight that could permit an attacker to break this algorithm, even in principle. That contrasts with other primitives which are often insecure given an efficient P=NP solution (guess the right answer and check that it was correct). With the one-time pad and Shamir's Secret Sharing, the attacker has no meaningful way to check whether the guessed answer was correct or not. (Both algorithms have a requirement for random input, and the information-theoretic security argument assumes that the attacker could never predict any information about your randomness source, which might not always be true if you're running on real hardware. If you're driving the algorithm with the output of a CSPRNG, the information-theoretic security may reduce to the security of your CSPRNG, which is not information-theoretically secure, for example because an attacker who could somehow guess the CSPRNG seed and offset could potentially confirm that this guess was right.) Another way of thinking about this is the a brute force attack on a security system requires a way to detect when your current guess is right. This is why, for example, the RSA encryption challenges would always have a plaintext starting with "The unknown message is:". This assumption isn't necessarily that unrealistic if you know that the plaintext of an encrypted message is a particular file format. Apparently a huge amount of military cryptanalysis, once governments started building special-purpose hardware for brute-force-like attacks, consisted in trying to find and refine ways to usefully detect when the attack had succeeded, given relatively great uncertainty about the nature of the plaintext. It also appears that many of those plaintext-recognition ideas are still classified (!). In an information-theoretically secure algorithm, there is no way to detect a successful break of the algorithm because all plaintexts are equally possible and equally likely given only the evidence of the ciphertext. That means that the ciphertext itself doesn't contribute any new information about the plaintext, so there's in some sense nothing to worry about from sharing the ciphertext with an adversary.
  - deleted 6y ago
    [deleted]
  - peterwwillis 6y ago
    Haha, and I was thinking "Wait, is one-time pad the other one?" before clicking! Too bad, since one-time pad is only theoretically secure. Too many ways to break it in practice.
    - p4bl0 6y ago
      Well, if used correctly, it is practically secure, and otherwise it's not really a one-time pad.
gh123man 6y ago
Very cool. FYI the whole page breaks if you accidentally delete the "shares" value or type 0, requiring a refresh to revive it.
- l1am0 6y ago
  Thanks for that bug report! On the go right now, will fix this in about 3 hours! Edit: Fixed
analyte123 6y ago
Hate to be this guy, but things trying to be like this should implement a CSP with `connect-src 'none'` (and `form-action: 'none'` and `self` restrictions on everything else). Otherwise I can't be assured that the secrets won't be sent off without disconnecting my network interface.
- l1am0 6y ago
  Love you being this guy as this is a very valid point! I am on the go right now, but will ad this in about 2 hours.
- thinkloop 6y ago
  CSP = Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP "To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore). Alternatively, the <meta> element can be used to configure a policy, for example: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; https://*; child-src 'none';">"
- dylz 6y ago
  You can't be assured that they will send that CSP header or meta tag with every request, either. If your threat model includes this, might as well save the page locally.
  - zaroth 6y ago
    I think the point is that you go to the site, and save the HTML on your local machine, and then run it from there. It would be amazing if there was a property you could add to the <html> tag to enforce that the browser would prevent any network access or disk writes. As it stands I think after you save the files, you would have to look into each .js file downloaded as part of the bundle to check for outgoing network requests? The code is tiny except for vue_debug.js which is 193KB.
thinkloop 6y ago
Shamir is one of the suggested ways to restore crypto in case of death with more decentralized trust. You select 20 friends and give them each one of the keys, then at your funeral 10 or more of them come together to unlock your wallet and execute your will. But it has a big problem: rot. It needs to be accompanied by a system that ensures everything is still in tact. The system would ping every key holder every X months and have them prove they are still in possession of their key. If a problem arises the wallet owner is alerted to deal with it. Otherwise she gets an all clear report. The annoying thing tho is now there is a centralized 3rd-party database of all your key holders. Part of the security is nobody knowing who's in on it. Imagine a wallet with $100M. That database starts becoming valuable. So the service would have to be zero-knowledge or hosted, but now you're hosting stuff, and not just any stuff, the most valuable stuff, requiring top security.
- Canada 6y ago
  The other problem is that the shares must be combined to recover the secret and doing that safely is hard. It's not a problem if the use case is say, protecting the recovery key for my laptop by giving shares to friends. But in the case of bitcoin, who's going to be allowed to see the resulting secret? Might result in a race to steal the coins. So then there has to be more than 1 group of SSS, with each one getting key for a multisig wallet... or some other carefully executed key ceremony... and the more of such things that are required the more fragile the scheme becomes in practice.
  - thinkloop 6y ago
    I envisioned the keys coming together at the notary's along with the rest of the estate, with a transaction immediately executed to the final recipient. This is a semi-trusted setup after-all. Also the final recipient would likely be one of the key holders present at the ceremony.
- nope96 6y ago
  I have usually seen multisig as the recommended way, not Shamir. One Shamir vs multisig article : https://medium.com/clavestone/bitcoin-multisig-vs-shamirs-secret-sharing-scheme-ea83a888f033 https://medium.com/clavestone/bitcoin-multisig-vs-shamirs-se...
e79 6y ago
While SSSS provides information theoretic security, there are a couple of security gotchas. One example is that it leaks the length of a secret unless padding is used. In practice this isn’t usually an issue, since many applications (like this one) use SSSS for sharing fixed-size symmetric keys. A more concerning gotcha is that this scheme doesn’t produce verified shares (i.e., shares lack integrity). An adversarial or forgetful share holder can submit a bad share and within this scheme, you’d have no way of being able to prove that they did this. All any of the participants would know is that the resulting secret is wrong, whatever that means for the application (e.g., the AES key doesn’t successfully decrypt a ciphertext).
- kcolford 6y ago
  Can't these problems be solved with another layer like signing with a pubkey where the private is thrown away after issuance? And then maybe some error correcting algorithm to avoid forgetful users?
  - matthewaveryusa 6y ago
    Signing the shards was the first thing I thought of as well. This will completely thwart bad shards from being mixed into the decryption.
- l1am0 6y ago
  If you have any algorithm or source at hand I would be really happy to add this! Or even better: If you got some time spare, feel free to help out with s4 :D https://github.com/simonfrey/s4 https://github.com/simonfrey/s4
- y7 6y ago
  If you're secret-sharing a symmetric key then you're dealing with computational security anyway, but you do get some notion of integrity for free. As you said, given a reconstructing set of shares you can tell whether all shares are correct, or whether they aren't (but you are not able to identify the bad share). However, if you have additional good shares (enough good shares to reconstruct), then you will be able to identify the bad shares. You could also use digital signatures on the shares to get integrity for individual shares.
kickscondor 6y ago
> You can find the code on Github and this website works completely offline. Save it to your computer (Ctrl+S) in order to not loose access to the s4 in case this website will be down at any point in the future. I'm also seeding this on Beaker. hyper://467f73aff5af260ab04a4f064fa8cd7fda6f23fed4ff227bc29514c3381a2087/
- l1am0 6y ago
  Would you be so kind and further explain what Beaker is?
  - aspenmayer 6y ago
    Not OP, but here's some info. Beaker Browser https://beakerbrowser.com/ https://beakerbrowser.com/ which uses Hypercore Protocol https://hypercore-protocol.org/ https://hypercore-protocol.org/
- bscphil 6y ago
  I've put it on IPFS too. https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs6MKWntU/ https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs... IDK what Beaker is exactly, but the nice thing about IPFS is that this hash is guaranteed to correspond to this commit: https://github.com/simonfrey/s4/commit/1d169cb33761b57569e52e4e0b11cc2baa1ad8e2 https://github.com/simonfrey/s4/commit/1d169cb33761b57569e52... - it can't be modified (by me or anyone else) in the future.
  - kickscondor 6y ago
    This seems to be a good fit for IPFS, since it's a single page with no absolute paths. While Beaker does let me update the source code at that location - you can also link to the current version permanently by adding the version number (46, in this case) to the end. hyper://467f73aff5af260ab04a4f064fa8cd7fda6f23fed4ff227bc29514c3381a2087+46/
klyrs 6y ago
This is really neat! I found a minor issue; changing the number of shares on the decode panel (after a successful decode) seems to freeze the output; using a recent firefox on linux.
- l1am0 6y ago
  Thanks for reporting! Fixed :)
l1am0 6y ago
Aaarg. The save to local file does not work as of javascript fetch not being able to load local resources. Anyone any ideas how to cirumvent that problem. (The webassembly is loaded via fetch())
- l1am0 6y ago
  Yay, got that fixed with data urls :D Now works also as downloaded file.
chosenken 6y ago
Placed on IPFS as well because why not. http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41EVY7BZ http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41...
- thinkloop 6y ago
  Are you pinning it on your server, is that how that works?
mirimir 6y ago
Interesting. But what about ssss? Also, I vaguely recall that results may be implementation specific, in that shares must be combined with the same app that produced them. So is this implementation compatible with others?
- e79 6y ago
  SSSS is Shamir’s Secret Sharing Scheme. Sort of. Different apps may use different finite fields. The math should be the same as long as you’re computing everything modulo the same integer. It is also possible that some apps may encode shares differently. For example, I’ve seen some apps base64-encode each share where others keep them as integers.
l8again 6y ago
I am not able to decrypt when I set the minimum shards to 3 out of 5. Works with 2.
- l1am0 6y ago
  Thanks for that report! Is a problem with the javascript. Should be fix in about 20 min Edit: Fixed
CortexM4 6y ago
Love to be this guy, good way to crash the browser. Set share size to 1000+ and Enjoy!
- l1am0 6y ago
  The GUI starts to look quite shitty around 10 shares already. Something I should work on. The above mentioned 1000+ share problem could only be solved by a limit, but I would be in favor of not limiting users here. p.S. On firefox it only chrashes the tab
NKosmatos 6y ago
Nice work and extra points for being super responsive to bugs/fixes/recommendations from comments :-) Reminds me of something similar: https://iancoleman.io/shamir/ https://iancoleman.io/shamir/
- l1am0 6y ago
  Yepp I do know about that one, but it is based on an outdated js library :/ https://github.com/amper5and/secrets.js https://github.com/amper5and/secrets.js
dartf 6y ago
Hate to be this guy, but it doesn't work with unicode.
- l1am0 6y ago
  Thanks for reporting! The encryption actually works with unicode (as it is go) but apparently vue.js does have a problem with it. Will check how to solve this :D

180 points by l1am0 6y ago

This is really cool! Very small suggestion, I'd put Minimum required shares ahead of Shares so that it follows the m-of-n order.

l1am0 6y ago
Nice UX improvement. Will add it Edit: Added

deleted 6y ago

[deleted]

jaspax 6y ago

A very minor nit: Your placeholder text begins "What every message", where I'm pretty sure you meant "Whatever message". Initially confusing until I figured out what you meant.

l1am0 6y ago
Damn. This should not have happened. Thanks for that note:) Will change that asap Edit: Fixed together with other spelling mistakes

ISL 6y ago

I didn't know the algorithm: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

schoen 6y ago
A fun fact is that this is one of only two algorithms in https://en.wikipedia.org/wiki/Category:Information-theoretically_secure_algorithms https://en.wikipedia.org/wiki/Category:Information-theoretic... The idea is that there is no amount of computational capacity or mathematical insight that could permit an attacker to break this algorithm, even in principle. That contrasts with other primitives which are often insecure given an efficient P=NP solution (guess the right answer and check that it was correct). With the one-time pad and Shamir's Secret Sharing, the attacker has no meaningful way to check whether the guessed answer was correct or not. (Both algorithms have a requirement for random input, and the information-theoretic security argument assumes that the attacker could never predict any information about your randomness source, which might not always be true if you're running on real hardware. If you're driving the algorithm with the output of a CSPRNG, the information-theoretic security may reduce to the security of your CSPRNG, which is not information-theoretically secure, for example because an attacker who could somehow guess the CSPRNG seed and offset could potentially confirm that this guess was right.) Another way of thinking about this is the a brute force attack on a security system requires a way to detect when your current guess is right. This is why, for example, the RSA encryption challenges would always have a plaintext starting with "The unknown message is:". This assumption isn't necessarily that unrealistic if you know that the plaintext of an encrypted message is a particular file format. Apparently a huge amount of military cryptanalysis, once governments started building special-purpose hardware for brute-force-like attacks, consisted in trying to find and refine ways to usefully detect when the attack had succeeded, given relatively great uncertainty about the nature of the plaintext. It also appears that many of those plaintext-recognition ideas are still classified (!). In an information-theoretically secure algorithm, there is no way to detect a successful break of the algorithm because all plaintexts are equally possible and equally likely given only the evidence of the ciphertext. That means that the ciphertext itself doesn't contribute any new information about the plaintext, so there's in some sense nothing to worry about from sharing the ciphertext with an adversary.
- deleted 6y ago
  [deleted]
- peterwwillis 6y ago
  Haha, and I was thinking "Wait, is one-time pad the other one?" before clicking! Too bad, since one-time pad is only theoretically secure. Too many ways to break it in practice.
  - p4bl0 6y ago
    Well, if used correctly, it is practically secure, and otherwise it's not really a one-time pad.

gh123man 6y ago

Very cool. FYI the whole page breaks if you accidentally delete the "shares" value or type 0, requiring a refresh to revive it.

l1am0 6y ago
Thanks for that bug report! On the go right now, will fix this in about 3 hours! Edit: Fixed

analyte123 6y ago

Hate to be this guy, but things trying to be like this should implement a CSP with `connect-src 'none'` (and `form-action: 'none'` and `self` restrictions on everything else). Otherwise I can't be assured that the secrets won't be sent off without disconnecting my network interface.

l1am0 6y ago
Love you being this guy as this is a very valid point! I am on the go right now, but will ad this in about 2 hours.
thinkloop 6y ago
CSP = Content Security Policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP "To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the X-Content-Security-Policy header, but that's an older version and you don't need to specify it anymore). Alternatively, the <meta> element can be used to configure a policy, for example: <meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; https://*; child-src 'none';">"
dylz 6y ago
You can't be assured that they will send that CSP header or meta tag with every request, either. If your threat model includes this, might as well save the page locally.
- zaroth 6y ago
  I think the point is that you go to the site, and save the HTML on your local machine, and then run it from there. It would be amazing if there was a property you could add to the <html> tag to enforce that the browser would prevent any network access or disk writes. As it stands I think after you save the files, you would have to look into each .js file downloaded as part of the bundle to check for outgoing network requests? The code is tiny except for vue_debug.js which is 193KB.

thinkloop 6y ago

Shamir is one of the suggested ways to restore crypto in case of death with more decentralized trust. You select 20 friends and give them each one of the keys, then at your funeral 10 or more of them come together to unlock your wallet and execute your will. But it has a big problem: rot. It needs to be accompanied by a system that ensures everything is still in tact. The system would ping every key holder every X months and have them prove they are still in possession of their key. If a problem arises the wallet owner is alerted to deal with it. Otherwise she gets an all clear report. The annoying thing tho is now there is a centralized 3rd-party database of all your key holders. Part of the security is nobody knowing who's in on it. Imagine a wallet with $100M. That database starts becoming valuable. So the service would have to be zero-knowledge or hosted, but now you're hosting stuff, and not just any stuff, the most valuable stuff, requiring top security.

Canada 6y ago
The other problem is that the shares must be combined to recover the secret and doing that safely is hard. It's not a problem if the use case is say, protecting the recovery key for my laptop by giving shares to friends. But in the case of bitcoin, who's going to be allowed to see the resulting secret? Might result in a race to steal the coins. So then there has to be more than 1 group of SSS, with each one getting key for a multisig wallet... or some other carefully executed key ceremony... and the more of such things that are required the more fragile the scheme becomes in practice.
- thinkloop 6y ago
  I envisioned the keys coming together at the notary's along with the rest of the estate, with a transaction immediately executed to the final recipient. This is a semi-trusted setup after-all. Also the final recipient would likely be one of the key holders present at the ceremony.
nope96 6y ago
I have usually seen multisig as the recommended way, not Shamir. One Shamir vs multisig article : https://medium.com/clavestone/bitcoin-multisig-vs-shamirs-secret-sharing-scheme-ea83a888f033 https://medium.com/clavestone/bitcoin-multisig-vs-shamirs-se...

e79 6y ago

While SSSS provides information theoretic security, there are a couple of security gotchas. One example is that it leaks the length of a secret unless padding is used. In practice this isn’t usually an issue, since many applications (like this one) use SSSS for sharing fixed-size symmetric keys. A more concerning gotcha is that this scheme doesn’t produce verified shares (i.e., shares lack integrity). An adversarial or forgetful share holder can submit a bad share and within this scheme, you’d have no way of being able to prove that they did this. All any of the participants would know is that the resulting secret is wrong, whatever that means for the application (e.g., the AES key doesn’t successfully decrypt a ciphertext).

kcolford 6y ago
Can't these problems be solved with another layer like signing with a pubkey where the private is thrown away after issuance? And then maybe some error correcting algorithm to avoid forgetful users?
- matthewaveryusa 6y ago
  Signing the shards was the first thing I thought of as well. This will completely thwart bad shards from being mixed into the decryption.
l1am0 6y ago
If you have any algorithm or source at hand I would be really happy to add this! Or even better: If you got some time spare, feel free to help out with s4 :D https://github.com/simonfrey/s4 https://github.com/simonfrey/s4
y7 6y ago
If you're secret-sharing a symmetric key then you're dealing with computational security anyway, but you do get some notion of integrity for free. As you said, given a reconstructing set of shares you can tell whether all shares are correct, or whether they aren't (but you are not able to identify the bad share). However, if you have additional good shares (enough good shares to reconstruct), then you will be able to identify the bad shares. You could also use digital signatures on the shares to get integrity for individual shares.

kickscondor 6y ago

> You can find the code on Github and this website works completely offline. Save it to your computer (Ctrl+S) in order to not loose access to the s4 in case this website will be down at any point in the future. I'm also seeding this on Beaker. hyper://467f73aff5af260ab04a4f064fa8cd7fda6f23fed4ff227bc29514c3381a2087/

l1am0 6y ago
Would you be so kind and further explain what Beaker is?
- aspenmayer 6y ago
  Not OP, but here's some info. Beaker Browser https://beakerbrowser.com/ https://beakerbrowser.com/ which uses Hypercore Protocol https://hypercore-protocol.org/ https://hypercore-protocol.org/
bscphil 6y ago
I've put it on IPFS too. https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs6MKWntU/ https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs... IDK what Beaker is exactly, but the nice thing about IPFS is that this hash is guaranteed to correspond to this commit: https://github.com/simonfrey/s4/commit/1d169cb33761b57569e52e4e0b11cc2baa1ad8e2 https://github.com/simonfrey/s4/commit/1d169cb33761b57569e52... - it can't be modified (by me or anyone else) in the future.
- kickscondor 6y ago
  This seems to be a good fit for IPFS, since it's a single page with no absolute paths. While Beaker does let me update the source code at that location - you can also link to the current version permanently by adding the version number (46, in this case) to the end. hyper://467f73aff5af260ab04a4f064fa8cd7fda6f23fed4ff227bc29514c3381a2087+46/

klyrs 6y ago

This is really neat! I found a minor issue; changing the number of shares on the decode panel (after a successful decode) seems to freeze the output; using a recent firefox on linux.

l1am0 6y ago
Thanks for reporting! Fixed :)

l1am0 6y ago

Aaarg. The save to local file does not work as of javascript fetch not being able to load local resources. Anyone any ideas how to cirumvent that problem. (The webassembly is loaded via fetch())

l1am0 6y ago
Yay, got that fixed with data urls :D Now works also as downloaded file.

chosenken 6y ago

Placed on IPFS as well because why not. http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41EVY7BZ http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41...

thinkloop 6y ago
Are you pinning it on your server, is that how that works?

mirimir 6y ago

Interesting. But what about ssss? Also, I vaguely recall that results may be implementation specific, in that shares must be combined with the same app that produced them. So is this implementation compatible with others?

e79 6y ago
SSSS is Shamir’s Secret Sharing Scheme. Sort of. Different apps may use different finite fields. The math should be the same as long as you’re computing everything modulo the same integer. It is also possible that some apps may encode shares differently. For example, I’ve seen some apps base64-encode each share where others keep them as integers.

l8again 6y ago

I am not able to decrypt when I set the minimum shards to 3 out of 5. Works with 2.

l1am0 6y ago
Thanks for that report! Is a problem with the javascript. Should be fix in about 20 min Edit: Fixed

CortexM4 6y ago

Love to be this guy, good way to crash the browser. Set share size to 1000+ and Enjoy!

l1am0 6y ago
The GUI starts to look quite shitty around 10 shares already. Something I should work on. The above mentioned 1000+ share problem could only be solved by a limit, but I would be in favor of not limiting users here. p.S. On firefox it only chrashes the tab

NKosmatos 6y ago

Nice work and extra points for being super responsive to bugs/fixes/recommendations from comments :-) Reminds me of something similar: https://iancoleman.io/shamir/ https://iancoleman.io/shamir/

l1am0 6y ago
Yepp I do know about that one, but it is based on an outdated js library :/ https://github.com/amper5and/secrets.js https://github.com/amper5and/secrets.js

dartf 6y ago

Hate to be this guy, but it doesn't work with unicode.

l1am0 6y ago
Thanks for reporting! The encryption actually works with unicode (as it is go) but apparently vue.js does have a problem with it. Will check how to solve this :D