Timeline for Shamir secret sharing beats XOR in theory or in practice too?
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 15 at 3:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jun 17 at 2:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| May 18 at 1:44 | answer | added | benrg | timeline score: 0 | |
| May 17 at 17:37 | comment | added | kelalaka | I was generic. like this one? github.com/shea256/secret-sharing | |
| May 17 at 16:48 | history | edited | ghosts_in_the_code | CC BY-SA 4.0 |
added 324 characters in body
|
| May 17 at 16:42 | comment | added | ghosts_in_the_code | @kelalaka I didn’t understand what your first two sentences are replying to, I agree with them though! If you have time can you suggest a specific tool? (One that has good design, tested extensively, doesn’t require me to worry about whether the tool will exist 10 years from now or how I will run it) | |
| May 17 at 16:23 | comment | added | kelalaka | $(t, n)$ is important because people may die. Also, the shares must be in separate places since we can have catastrophic events that may destroy all at once. For the software part, there should be open source(d) software that exists in various VCS sites and must be tested extensively. | |
| May 17 at 16:10 | comment | added | ghosts_in_the_code | @kelalaka Also I would love your advice on what tool I should use today. Should I use ssss on Linux or should I avoid using secret sharing altogether? Even a 5% chance of losing all the data would be unacceptable to me, 1% could be okay though. | |
| May 17 at 16:07 | comment | added | ghosts_in_the_code | @kelalaka Could you please elaborate? I’m worried we’re talking past each other without understanding each other. Yes ssss on Linux can be used, I’m not sure why Paypal didnt use this tool or whatever previous tool existed at the time. I’m guessing it wasn’t standard enough hence they rolled their own solution. And standardising a tool also means standardising design patterns around the tool, no? Like gpg could just export private keys in plaintext and we could blame the dev if someone hacks their device for the keys, but gpg authors decided that encrypted private key is a better export format | |
| May 17 at 9:28 | comment | added | kelalaka | PayPal's problem is not about missing a standard solution this is about not knowing what you dealt with. SSS is already can be deal t shares out of n, long time ago. | |
| May 17 at 8:30 | comment | added | ghosts_in_the_code | @Mikero Like, people including me or the engineers at PayPal feel pressured to roll their own crypto because standard solutions aren't available. | |
| May 17 at 8:28 | comment | added | ghosts_in_the_code | @Mikero Fair enough. I'm just pointing out at the need for a stress-tested implementation. I don't have formal background in cryptography or security, but if I had to guess it will take less years and less number of people to release a stress-tested tool for xor secret sharing that would nudge Paypal engineers away from making bad design choices like the ones they did. | |
| May 17 at 8:25 | comment | added | ghosts_in_the_code | @ellipsoid I understand this! That's why I'm asking if there's any real world use case of SSSS that needs more than 10 participants. (Or is 10C5 = 252 keys already too large for some use case?) | |
| May 17 at 2:53 | comment | added | Mikero | Thanks for sharing that anecdote about PayPal and their secret sharing disaster. I hadn't heard it before. I don't think the story has any bearing on Shamir sharing vs XOR sharing, though. The story would have played out exactly the same if they had used XOR sharing. Still, I enjoyed hearing the anecdote. | |
| May 16 at 22:02 | comment | added | ellipsoid | As the wikipedia article says for the case of $1<t<n$ you need ${n \choose t}$ shares. When $t=n/2$, then this term becomes exponential in $n$. For small, fixed numbers this seems to be no problem, but asymptotically it is. | |
| May 16 at 12:27 | comment | added | ghosts_in_the_code | *4 out of 7 secret shares (not signatures sorry) | |
| May 16 at 12:22 | comment | added | ghosts_in_the_code | For "MPC + secret sharing" too I am curious if any of the practical applications required a large number of participants (like >10 or >20). I will read more on this. | |
| May 16 at 12:21 | comment | added | ghosts_in_the_code | @ellipsoid Thanks for replying! I will go through the book. You are right I didn't pay enough attention to MPC because I was more focussed on backups. I didn't understand why having a threshold of half matters, if you need any 4 out of 7 signatures on your company board for example, this can be done with XOR approach in wikipedia article. Being able to add/delete members without having to again securely communicate with existing members seems super important, you are right I will think about this more. | |
| May 16 at 11:27 | comment | added | ellipsoid | I think your initial assumption that "the main practical use case of secret sharing is backups" is incorrect: At least a very common and important application of secret sharing is multiparty computation (here you find a really nice book on (pragmatic) MPC by Evans, Kolesnikov, and Rosulek). Also, often you want to tackle settings where a certain threshold (like half) of all shares is required. Even for backups think of the case when one of your devices/prints is destroyed => You want to add redundancy. That's where the trivial approach is bad in practice. | |
| May 16 at 10:32 | history | migrated | from security.stackexchange.com (revisions) | ||
| May 16 at 9:57 | history | asked | ghosts_in_the_code | CC BY-SA 4.0 |