
Show HN: 100% offline Shamir's Secret Sharing GUI - l1am0
https://simon-frey.com/s4/
======
analyte123
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
The problem with connect-src 'none' is that is does not allow the webassembly
to load than (as this is loaded via js)

`Content Security Policy: The page’s settings blocked the loading of a
resource at
[http://localhost:8080/wasm/wasm.wasm](http://localhost:8080/wasm/wasm.wasm)
(“connect-src”).`

For now I only added `default-src: 'self'; form-action 'none'` to the
index.html

~~~
jerry1979
Why not just embed the wasm directly in the webpage?

~~~
l1am0
Funny I came up with the same idea about 10min ago :D It is now directly
embedded via a data uri.

This allows to set `connect-src: 'data'`

------
e79
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
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
Signing the shards was the first thing I thought of as well. This will
completely thwart bad shards from being mixed into the decryption.

------
ISL
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
A fun fact is that this is one of only two algorithms in

[https://en.wikipedia.org/wiki/Category:Information-
theoretic...](https://en.wikipedia.org/wiki/Category:Information-
theoretically_secure_algorithms)

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.

~~~
peterwwillis
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
Well, if used correctly, it _is_ practically secure, and otherwise it's not
really a one-time pad.

------
aprao
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
Nice UX improvement. Will add it

Edit: Added

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

~~~
nope96
I have usually seen multisig as the recommended way, not Shamir.

One Shamir vs multisig article : [https://medium.com/clavestone/bitcoin-
multisig-vs-shamirs-se...](https://medium.com/clavestone/bitcoin-multisig-vs-
shamirs-secret-sharing-scheme-ea83a888f033)

~~~
e79
[removed]

~~~
thinkloop
The only thing I don't like about that is that it is dependent on the network.
Some cryptos don't have multi-sig for example. It's a full system, you have to
be aware of protocol changes and such - Shamir is straight math and works on
any type of key independent of the system. Trade-offs as usual I guess.

------
gh123man
Very cool.

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

~~~
l1am0
Thanks for that bug report! On the go right now, will fix this in about 3
hours!

Edit: Fixed

------
l1am0
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
Yay, got that fixed with data urls :D Now works also as downloaded file.

------
kickscondor
> 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/

~~~
bscphil
I've put it on IPFS too.
[https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs...](https://ipfs.io/ipfs/Qmdg6io4ZbdRdW92yUjeL2DHhcdNF3jCF2XWwDs6MKWntU/)

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/1d169cb33761b57569e52...](https://github.com/simonfrey/s4/commit/1d169cb33761b57569e52e4e0b11cc2baa1ad8e2)
\- it can't be modified (by me or anyone else) in the future.

~~~
kickscondor
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/

------
NKosmatos
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
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)

------
chosenken
Placed on IPFS as well because why not.

[http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41...](http://ipfs.io/ipfs/QmZqRpnRgvBPbP65pdyD2fYhDh9VDEW4EGb5kM41EVY7BZ)

~~~
thinkloop
Are you pinning it on your server, is that how that works?

------
klyrs
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
Thanks for reporting! Fixed :)

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

~~~
l1am0
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

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

------
jaspax
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
Damn. This should not have happened. Thanks for that note:) Will change that
asap

Edit: Fixed together with other spelling mistakes

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

~~~
l1am0
Thanks for that report! Is a problem with the javascript. Should be fix in
about 20 min

Edit: Fixed

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

~~~
l1am0
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

