Secret sharing

<h2 id="importance">Importance</h2>
Secret sharing schemes are ideal for storing information that is highly sensitive and highly important. Examples include: <a href="/facts/Encryption_key/5W5PAmT4">encryption keys</a>, <a href="/facts/Nuclear_football/50ofEk0X">missile launch codes</a>, and <a href="/facts/Numbered_bank_account/eFF1sL0T">numbered bank accounts</a>. Each of these pieces of information must be kept highly confidential, as their exposure could be disastrous; however, it is also critical that they should not be lost. Traditional methods for encryption are ill-suited for simultaneously achieving high levels of confidentiality and reliability. This is because when storing the encryption key, one must choose between keeping a single copy of the key in one location for maximum secrecy, or keeping multiple copies of the key in different locations for greater reliability. Increasing reliability of the key by storing multiple copies lowers confidentiality by creating additional attack vectors; there are more opportunities for a copy to fall into the wrong hands. Secret sharing schemes address this problem, and allow arbitrarily high levels of confidentiality and reliability to be achieved.<a class="footnote-ref" id="fnref:3" href="#fn:3">3</a>
Secret sharing also allows the distributor of the secret to trust a group 'in aggregate'. Traditionally, giving a secret to a group for safekeeping would require that the distributor completely trust all members of the group. Secret sharing schemes allow the distributor to securely store the secret with the group even if not all members can be trusted all the time. So long as the number of traitors is never more than the critical number needed to reconstruct the secret, the secret is safe.
Secret sharing schemes are important in <a href="/facts/Cloud_computing/guhg0FGV">cloud computing</a> environments. Thus a key can be distributed over many servers by a threshold secret sharing mechanism. The key is then reconstructed when needed.
Secret sharing has also been suggested[by whom?] for <a href="/facts/Sensor_networks/r5LIAVsU">sensor networks</a> where the links are liable to be tapped, by sending the data in shares which makes the task of the eavesdropper harder. The security in such environments can be made greater by continuous changing[how?] of the way the shares are constructed.

<h2 id="secure-versus-insecure-secret-sharing">"Secure" versus "insecure" secret sharing</h2>
A secure secret sharing scheme distributes shares so that anyone with fewer than t shares has no more information about the secret than someone with 0 shares.
Consider for example the secret sharing scheme in which the secret phrase "password" is divided into the shares "pa––––––", "––ss––––", "––––wo––", and "––––––rd". A person with 0 shares knows only that the password consists of eight letters, and thus would have to guess the password from 268 = 208 billion possible combinations. A person with one share, however, would have to guess only the six letters, from 266 = 308 million combinations, and so on as more persons collude. Consequently, this system is not a "secure" secret sharing scheme, because a player with fewer than t secret shares is able to reduce the problem of obtaining the inner secret without first needing to obtain all of the necessary shares.
In contrast, consider the secret sharing scheme where X is the secret to be shared, Pi are public <a href="/facts/Public-key_cryptography/gowoFTxS">asymmetric encryption</a> keys and Qi their corresponding private keys. Each player J is provided with {P1(P2(...(PN(X)))), Qj}. In this scheme, any player with private key 1 can remove the outer layer of encryption, a player with keys 1 and 2 can remove the first and second layer, and so on. A player with fewer than N keys can never fully reach the secret X without first needing to decrypt a public-key-encrypted blob for which he does not have the corresponding private key – a problem that is currently believed to be computationally infeasible. Additionally we can see that any user with all N private keys is able to decrypt all of the outer layers to obtain X, the secret, and consequently this system is a secure secret distribution system.

<h2 id="limitations">Limitations</h2>
Several secret-sharing schemes are said to be <a href="/facts/Information-theoretic_security/DG2q6XeI">information-theoretically secure</a> and can be proven to be so, while others give up this unconditional security for improved efficiency while maintaining enough security to be considered as secure as other common cryptographic primitives. For example, they might allow secrets to be protected by shares with entropy of 128 bits each, since each share would be considered enough to stymie any conceivable present-day adversary, requiring a brute force attack of average size 2127.
Common to all unconditionally secure secret sharing schemes, there are limitations:

<ul><li>Each share of the secret must be at least as large as the secret itself. This result is based in <a href="/facts/Information_theory/qNLH3U5P">information theory</a>, but can be understood intuitively. Given t − 1 shares, no information whatsoever can be determined about the secret. Thus, the final share must contain as much information as the secret itself. There is sometimes a workaround for this limitation by first <a href="/facts/Data_compression/gMFuY4FT">compressing</a> the secret before sharing it, but this is often not possible because many secrets (keys for example) look like high-quality random data and thus are hard to compress.</li>
<li>All secret-sharing schemes use <a href="/facts/Random/QJQBoEX5">random</a> <a href="/facts/Bit/RwfjaYSv">bits</a> for constructing the shares. To distribute a one-bit secret shares with a threshold of t shares, t − 1 random bits are needed. To distribute a secret of b bits, entropy of (t − 1) × b bits is necessary.</li></ul>
<h2 id="trivial-secret-sharing">Trivial secret sharing</h2>
Note: n is the total number of 'players', among whom the shares are distributed, and t is the minimum number of players required to reveal the secret.

<h3>t = 1</h3>
t = 1 secret sharing is trivial. The secret can simply be distributed to all n participants.

<h3>t = n</h3>
There are several (t, n) secret-sharing schemes for t = n, when all shares are necessary to recover the secret:

<ol><li>Encode the secret as a <a href="/facts/Binary_numeral_system/a6JDSRPs">binary</a> number s of any length. For each player i, where i is one fewer than the total number of players, give a random binary number pi of the same length as s. To the player without a share, give the share calculated as pn = s ⊕ p1 ⊕ p2 ⊕ ... ⊕ pn−1, where ⊕ denotes <a href="/facts/Bitwise_operation/0gkqnUda">bitwise exclusive or</a>. The secret is the bitwise exclusive-or of all the players' numbers (pi, for 1 ≤ i ≤ n).</li>
<li>Instead, (1) can be performed using the binary operation in any <a href="/facts/Group_(mathematics)/IQTYqINt">group</a>. For example, take the cyclic group of integers with addition modulo 232, which corresponds to 32-bit integers with addition defined with the binary overflow being discarded. The secret s can be partitioned into a vector of M 32-bit integers, which we call vsecret. Then (n − 1) of the players are each given a vector of M 32-bit integers that is drawn independently from a uniform probability distribution, with player i receiving vi. The remaining player is given vn = vsecret − v1 − v2 − ... − vn−1. The secret vector can then be recovered by summing across all the players' vectors.</li></ol>
<h3>1 < t < n</h3>
The difficulty lies in creating schemes that are still secure, but do not require all n shares.
When space efficiency is not a concern, trivial t = n schemes can be used to reveal a secret to any desired subsets of the players simply by applying the scheme for each subset. For example, to reveal a secret s to any two of the three players Alice, Bob and Carol, create three (
 
 
 
 
 
 
 (
 
 
 3
 2
 
 
 )
 
 
 
 
 
 {\displaystyle {\binom {3}{2}}}
 
) different t = n = 2 secret shares for s, giving the three sets of two shares to Alice and Bob, Alice and Carol, and Bob and Carol.

<h3>t belonging to any desired subset of {1, 2, ..., n}</h3>
For example, imagine that the board of directors of a company would like to protect their secret formula. The president of the company should be able to access the formula when needed, but in an emergency any 3 of the 12 board members would be able to unlock the secret formula together. One of the ways this can be accomplished is by a secret-sharing scheme with t = 3 and n = 15, where 3 shares are given to the president, and one share is given to each board member.

<h2 id="efficient-secret-sharing">Efficient secret sharing</h2>
The trivial approach quickly becomes impractical as the number of subsets increases, for example when revealing a secret to any 50 of 100 players, which would require 
 
 
 
 
 
 
 (
 
 
 100
 50
 
 
 )
 
 
 
 ≈
 1.009
 ×
 
 10
 
 29
 
 
 
 
 {\displaystyle {\binom {100}{50}}\approx 1.009\times 10^{29}}
 
 schemes to be created and each player to maintain 
 
 
 
 
 
 
 (
 
 
 99
 49
 
 
 )
 
 
 
 ≈
 5.04
 ×
 
 10
 
 28
 
 
 
 
 {\displaystyle {\binom {99}{49}}\approx 5.04\times 10^{28}}
 
 distinct sets of shares for each scheme. In the worst case, the increase is exponential. This has led to the search for schemes that allow secrets to be shared efficiently with a threshold of players.

<h3>Shamir's scheme</h3>
Main article: <a href="/facts/Shamir%2527s_secret_sharing/dv5yFFHY">Shamir's secret sharing</a>
In this scheme, any t out of n shares may be used to recover the secret. The system relies on the idea that one can construct a unique <a href="/facts/Polynomial/Lzak8VVx">polynomial</a> of degree t − 1, such that each of the t points lies on the polynomial. It takes two points to define a straight line, three points to fully define a quadratic, four points to define a cubic curve, and so on. That is, it takes t points to define a polynomial of degree t − 1. The method is to create a polynomial of degree t − 1 with the secret as the first coefficient and the remaining coefficients picked at random. Next find n points on the curve and give one to each of the players. When at least t out of the n players reveal their points, there is sufficient information to fit a (t − 1)th degree polynomial to them, the first coefficient being the secret.

<h3>Blakley's scheme</h3>
Two <a href="/facts/Parallel_(geometry)/16r5yq7D">nonparallel</a> lines in the same <a href="/facts/Plane_(mathematics)/tAUtRFcn">plane</a> intersect at exactly one point. Three nonparallel planes in space intersect at exactly one point. More generally, any n nonparallel <a href="/facts/Dimension/0ktmUyac">(n − 1)-dimensional</a> <a href="/facts/Hyperplane/2s2ycYYd">hyperplanes</a> intersect at a specific point. The secret may be encoded as any single coordinate of the point of intersection. If the secret is encoded using all the coordinates, even if they are random, then an insider (someone in possession of one or more of the <a href="/facts/Dimension/0ktmUyac">(n − 1)-dimensional</a> <a href="/facts/Hyperplane/2s2ycYYd">hyperplanes</a>) gains information about the secret since he knows it must lie on his plane. If an insider can gain any more knowledge about the secret than an outsider can, then the system no longer has <a href="/facts/Information_theoretic_security/DG2q6XeI">information theoretic security</a>. If only one of the n coordinates is used, then the insider knows no more than an outsider (i.e., that the secret must lie on the x-axis for a 2-dimensional system). Each player is given enough information to define a hyperplane; the secret is recovered by calculating the planes' point of intersection and then taking a specified coordinate of that intersection.

<table><tbody><tr><td></td><td></td><td></td></tr><tr><td colspan="3">Blakley's scheme in three dimensions: each share is a <a href="/facts/Plane_(mathematics)/tAUtRFcn">plane</a>, and the secret is the point at which three shares intersect. Two shares are insufficient to determine the secret, although they do provide enough information to narrow it down to the <a href="/facts/Line_(mathematics)/gJqsr4Gj">line</a> where both planes intersect.</td></tr></tbody></table>

Blakley's scheme is less space-efficient than Shamir's; while Shamir's shares are each only as large as the original secret, Blakley's shares are t times larger, where t is the threshold number of players. Blakley's scheme can be tightened by adding restrictions on which planes are usable as shares. The resulting scheme is equivalent to Shamir's polynomial system.

<h3>Using the Chinese remainder theorem</h3>
Main article: <a href="/facts/Secret_sharing_using_the_Chinese_remainder_theorem/3rgT9Bsz">Secret sharing using the Chinese remainder theorem</a>
The <a href="/facts/Chinese_remainder_theorem/7wwFIkuV">Chinese remainder theorem</a> can also be used in secret sharing, for it provides us with a method to uniquely determine a number S modulo k many <a href="/facts/Pairwise_coprime/bnCxCXxs">pairwise coprime</a> integers 
 
 
 
 
 m
 
 1
 
 
 ,
 
 m
 
 2
 
 
 ,
 .
 .
 .
 ,
 
 m
 
 k
 
 
 
 
 {\displaystyle m_{1},m_{2},...,m_{k}}
 
, given that 
 
 
 
 S
 <
 
 ∏
 
 i
 =
 1
 
 
 k
 
 
 
 m
 
 i
 
 
 
 
 {\displaystyle S<\prod _{i=1}^{k}m_{i}}
 
. There are two secret sharing schemes that make use of the Chinese remainder theorem, Mignotte's and Asmuth-Bloom's Schemes. They are threshold secret sharing schemes, in which the shares are generated by reduction modulo the integers 
 
 
 
 
 m
 
 i
 
 
 
 
 {\displaystyle m_{i}}
 
, and the secret is recovered by essentially solving the system of congruences using the Chinese remainder theorem.

<h2 id="proactive-secret-sharing">Proactive secret sharing</h2>
Main article: <a href="/facts/Proactive_secret_sharing/a3eU7VFA">Proactive secret sharing</a>
If the players store their shares on insecure computer servers, an <a href="/facts/Adversary_(cryptography)/X211CFfE">attacker</a> could crack in and steal the shares. If it is not practical to change the secret, the uncompromised (Shamir-style) shares can be renewed. The dealer generates a new random polynomial with constant term zero and calculates for each remaining player a new ordered pair, where the x-coordinates of the old and new pairs are the same. Each player then adds the old and new y-coordinates to each other and keeps the result as the new y-coordinate of the secret.
All of the non-updated shares the attacker accumulated become useless. An attacker can only recover the secret if he can find enough other non-updated shares to reach the threshold. This situation should not happen because the players deleted their old shares. Additionally, an attacker cannot recover any information about the original secret from the update files because they contain only random information.
The dealer can change the threshold number while distributing updates, but must always remain vigilant of players keeping expired shares.

<h2 id="verifiable-secret-sharing">Verifiable secret sharing</h2>
Main article: <a href="/facts/Verifiable_secret_sharing/IYngL3vr">Verifiable secret sharing</a>
A player might lie about his own share to gain access to other shares. A verifiable secret sharing (VSS) scheme allows players to be certain that no other players are lying about the contents of their shares, up to a reasonable probability of error. Such schemes cannot be computed conventionally; the players must collectively add and multiply numbers without any individual's knowing what exactly is being added and multiplied. <a href="/facts/Tal_Rabin/luIWn316">Tal Rabin</a> and <a href="/facts/Michael_Ben-Or/hf04G3fl">Michael Ben-Or</a> devised a <a href="/facts/Secure_multiparty_computation/7xJbbvIo">multiparty computing</a> (MPC) system that allows players to detect dishonesty on the part of the dealer or on part of up to one third of the threshold number of players, even if those players are coordinated by an "adaptive" attacker who can change strategies in realtime depending on what information has been revealed.

<h2 id="computationally-secure-secret-sharing">Computationally secure secret sharing</h2>
The disadvantage of unconditionally secure secret sharing schemes is that the storage and transmission of the shares requires an amount of storage and bandwidth resources equivalent to the size of the secret times the number of shares. If the size of the secret were significant, say 1 GB, and the number of shares were 10, then 10 GB of data must be stored by the shareholders. Alternate techniques have been proposed for greatly increasing the efficiency of secret sharing schemes, by giving up the requirement of unconditional security.
One of these techniques, known as secret sharing made short,<a class="footnote-ref" id="fnref:4" href="#fn:4">4</a> combines Rabin's information dispersal algorithm<a class="footnote-ref" id="fnref:5" href="#fn:5">5</a> (IDA) with Shamir's secret sharing. Data is first encrypted with a randomly generated key, using a symmetric encryption algorithm. Next this data is split into N pieces using Rabin's IDA. This IDA is configured with a threshold, in a manner similar to secret sharing schemes, but unlike secret sharing schemes the size of the resulting data grows by a factor of (number of fragments / threshold). For example, if the threshold were 10, and the number of IDA-produced fragments were 15, the total size of all the fragments would be (15/10) or 1.5 times the size of the original input. In this case, this scheme is 10 times more efficient than if Shamir's scheme had been applied directly on the data. The final step in secret sharing made short is to use Shamir secret sharing to produce shares of the randomly generated symmetric key (which is typically on the order of 16–32 bytes) and then give one share and one fragment to each shareholder.
A related approach, known as AONT-RS,<a class="footnote-ref" id="fnref:6" href="#fn:6">6</a> applies an <a href="/facts/All-or-nothing_transform/1tUzEuQ9">All-or-nothing transform</a> to the data as a pre-processing step to an IDA. The All-or-nothing transform guarantees that any number of shares less than the threshold is insufficient to decrypt the data.

<h2 id="multi-secret-and-space-efficient-batched-secret-sharing">Multi-secret and space efficient (batched) secret sharing</h2>
An information-theoretically secure k-of-n secret-sharing scheme generates n shares, each of size at least that of the secret itself, leading to the total required storage being at least n-fold larger than the secret. In multi-secret sharing designed by <a href="/facts/Matthew_K._Franklin/Vw7jruGp">Matthew K. Franklin</a> and <a href="/facts/Moti_Yung/KrBHvtts">Moti Yung</a>,<a class="footnote-ref" id="fnref:7" href="#fn:7">7</a> multiple points of the polynomial host secrets; the method was found useful in numerous applications from coding to <a href="/facts/Secure_multi-party_computation/7xJbbvIo">multi-party computations</a>. In space efficient secret sharing, devised by Abhishek Parakh and <a href="/facts/Subhash_Kak/FQLGwn3n">Subhash Kak</a>, each share is roughly the size of the secret divided by k − 1.<a class="footnote-ref" id="fnref:8" href="#fn:8">8</a>
This scheme makes use of repeated polynomial interpolation and has potential applications in secure information dispersal on the Web and in
<a href="/facts/Sensor_networks/r5LIAVsU">sensor networks</a>. This method is based on data partitioning involving the roots of a polynomial in finite field.<a class="footnote-ref" id="fnref:9" href="#fn:9">9</a> Some vulnerabilities of related space efficient secret sharing schemes were pointed out later.<a class="footnote-ref" id="fnref:10" href="#fn:10">10</a> They show that a scheme based on interpolation method cannot be used to implement a (k, n) scheme when the k secrets to be distributed are inherently generated from a polynomial of degree less than k − 1, and the scheme does not work if all of the secrets to be shared are the same, etc.<a class="footnote-ref" id="fnref:11" href="#fn:11">11</a>

<h2 id="other-uses-and-applications">Other uses and applications</h2>
A secret-sharing scheme can secure a secret over multiple servers and remain recoverable despite multiple server failures. The dealer may act as several distinct participants, distributing the shares among the participants. Each share may be stored on a different server, but the dealer can recover the secret even if several servers break down as long as they can recover at least t shares; however, <a href="/facts/Security_cracking/4bAJ9F1A">crackers</a> that break into one server would still not know the secret as long as fewer than t shares are stored on each server.
This is one of the major concepts behind the <a href="/facts/Vanish_(computer_science)/kzvCINLp">Vanish</a> computer project at the <a href="/facts/University_of_Washington/36PG6qkG">University of Washington</a>, where a random key is used to encrypt data, and the key is distributed as a secret across several nodes in a <a href="/facts/Peer-to-peer/wCCdPb0H">P2P</a> network. In order to decrypt the message, at least t nodes on the network must be accessible; the principle for this particular project being that the number of secret-sharing nodes on the network will decrease naturally over time, therefore causing the secret to eventually vanish. However, the network is vulnerable to a <a href="/facts/Sybil_attack/fqa8J81a">Sybil attack</a>, thus making Vanish insecure.<a class="footnote-ref" id="fnref:12" href="#fn:12">12</a>
Any shareholder who ever has enough information to decrypt the content at any point is able to take and store a copy of X. Consequently, although tools and techniques such as Vanish can make data irrecoverable within their own system after a time, it is not possible to force the deletion of data once a malicious user has seen it. This is one of the leading conundrums of <a href="/facts/Digital_rights_management/4AF8JmDt">digital rights management</a>.
A dealer could send t shares, all of which are necessary to recover the original secret, to a single recipient. An attacker would have to intercept all t shares to recover the secret, a task which is more difficult than intercepting a single file, especially if the shares are sent using different media (e.g. some over the <a href="/facts/Internet/Xw1rVvJU">Internet</a>, some mailed on <a href="/facts/Compact_Disc/g51GRloc">CDs</a>).
For large secrets, it may be more efficient to encrypt the secret and then distribute the key using secret sharing.
Secret sharing is an important primitive in several protocols for <a href="/facts/Secure_multiparty_computation/7xJbbvIo">secure multiparty computation</a>.
Secret sharing can also be used for user authentication in a system.<a class="footnote-ref" id="fnref:13" href="#fn:13">13</a>

<h2 id="see-also">See also</h2>

<ul><li><a href="/facts/Access_structure/IN8yDtd3">Access structure</a></li>
<li><a href="/facts/Byzantine_fault_tolerance/hucMXMBV">Byzantine fault tolerance</a></li>
<li><a href="/facts/Erasure_code/ea1C1z2X">Erasure code</a> – When the data to be reconstructed is not a secret</li>
<li><a href="/facts/Homomorphic_secret_sharing/RVP4fNGk">Homomorphic secret sharing</a> – A simplistic decentralized voting protocol.</li>
<li><a href="/facts/Orthogonal_array/BWWITMct">Orthogonal array</a> – Used to construct some threshold schemes.</li>
<li><a href="/facts/Publicly_verifiable_secret_sharing/reXuJ4UC">Publicly verifiable secret sharing</a></li>
<li><a href="/facts/Secret_sharing_using_the_Chinese_remainder_theorem/3rgT9Bsz">Secret sharing using the Chinese remainder theorem</a></li>
<li><a href="/facts/Secure_multiparty_computation/7xJbbvIo">Secure multiparty computation</a></li>
<li><a href="/facts/Shamir%2527s_secret_sharing/dv5yFFHY">Shamir's secret sharing</a></li>
<li><a href="/facts/Visual_cryptography/QCgbMqQY">Visual cryptography</a></li></ul>

<h2 id="external-links">External links</h2>
<ul><li><a href="http://manpages.ubuntu.com/manpages/zesty/en/man7/gfshare.7.html">Ubuntu Manpage: gfshare – explanation of Shamir Secret Sharing in GF(28)</a></li>
<li><a href="http://www.rsasecurity.com/rsalabs/node.asp?id=2259">Description of Shamir's and Blakley's schemes</a></li>
<li>Patent for use of secret sharing for recovering PGP (and other?) pass phrases <a href="https://patents.google.com/patent/US6662299">U.S. patent 6,662,299</a></li>
<li><a href="http://www.cacr.math.uwaterloo.ca/~dstinson/ssbib.html">A bibliography on secret-sharing schemes</a></li>
<li><a href="https://web.archive.org/web/20080214135432/http://www.xml-dev.com/blog/index.php?action=viewtopic&id=130">Code signing systems using Shared Secret</a> at the <a href="/facts/Wayback_Machine/nmQ3a6JC">Wayback Machine</a> (archived February 14, 2008)</li>
<li>Beimel, Amos (2011). <a href="http://www.cs.bgu.ac.il/~beimel/Papers/Survey.pdf">"Secret-Sharing Schemes: A Survey"</a> (PDF).</li></ul>

<h2 id="references">References</h2>

<ol>
<li id="fn:1">Shamir, Adi (1 November 1979). "How to share a secret" (PDF). Communications of the ACM. 22 (11): 612–613. doi:10.1145/359168.359176. S2CID 16321225. Archived (PDF) from the original on 2017-08-10. <a href="https://cs.jhu.edu/~sdoshi/crypto/papers/shamirturing.pdf" target="_blank">https://cs.jhu.edu/~sdoshi/crypto/papers/shamirturing.pdf</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></li>
<li id="fn:2">Blakley, G.R. (1979). "Safeguarding Cryptographic Keys" (PDF). Managing Requirements Knowledge, International Workshop on (AFIPS). 48: 313–317. doi:10.1109/AFIPS.1979.98. S2CID 38199738. Archived from the original (PDF) on 2018-06-28. <a href="https://web.archive.org/web/20180628164048/https://pdfs.semanticscholar.org/32d2/1ccc21a807627fcb21ea829d1acdab23be12.pdf" target="_blank">https://web.archive.org/web/20180628164048/https://pdfs.semanticscholar.org/32d2/1ccc21a807627fcb21ea829d1acdab23be12.pdf</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></li>
<li id="fn:3">Krenn, Stephan; Loruenser, Thomas (2023). An Introduction to Secret Sharing: A Systematic Overview and Guide for Protocol Selection. doi:10.1007/978-3-031-28161-7. ISBN 978-3-031-28160-0. (also available at [1]) <a href="978-3-031-28160-0" target="_blank">978-3-031-28160-0</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></li>
<li id="fn:4">Krawczyk, Hugo (1993). Secret Sharing Made Short (PDF). CRYPTO '93. <a href="http://www.cs.cornell.edu/courses/cs754/2001fa/secretshort.pdf" target="_blank">http://www.cs.cornell.edu/courses/cs754/2001fa/secretshort.pdf</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></li>
<li id="fn:5">Rabin, Michael O. (1989). "Efficient dispersal of information for security, load balancing, and fault tolerance". Journal of the ACM. 36 (2): 335–348. CiteSeerX 10.1.1.116.8657. doi:10.1145/62044.62050. S2CID 13166422. <a href="/wiki/CiteSeerX_(identifier)" target="_blank">/wiki/CiteSeerX_(identifier)</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></li>
<li id="fn:6">Resch, Jason; Plank, James (February 15, 2011). AONT-RS: Blending Security and Performance in Dispersed Storage Systems (PDF). Usenix FAST'11. <a href="http://web.eecs.utk.edu/~plank/plank/papers/FAST-2011.pdf" target="_blank">http://web.eecs.utk.edu/~plank/plank/papers/FAST-2011.pdf</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></li>
<li id="fn:7">Franklin, Matthew; Yung, Moti (4 May 1992). "Communication complexity of secure computation (Extended abstract)". Proceedings of the twenty-fourth annual ACM symposium on Theory of computing - STOC '92. pp. 699–710. doi:10.1145/129712.129780. ISBN 0897915119. S2CID 7486402. (also available at [2]) <a href="0897915119" target="_blank">0897915119</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></li>
<li id="fn:8">Parakh, Abhishek; Kak, Subhash (January 2011). "Space efficient secret sharing for implicit data security". Information Sciences. 181 (2): 335–341. doi:10.1016/j.ins.2010.09.013. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></li>
<li id="fn:9">Parakh, Abhishek; Kak, Subhash (September 2009). "Online data storage using implicit security". Information Sciences. 179 (19): 3323–3331. doi:10.1016/j.ins.2009.05.013. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></li>
<li id="fn:10">Sahasranand, K.R.; Nagaraj, Nithin; Rajan, S. (March 2010). "How not to share a set of secrets". International Journal of Computer Science and Information Security. arXiv:1001.1877. <a href="/wiki/ArXiv_(identifier)" target="_blank">/wiki/ArXiv_(identifier)</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></li>
<li id="fn:11">Liu, Yanhong; Zhang, Futai; Zhang, Jie (February 2016). "Attacks to some verifiable multi-secret sharing schemes and two improved schemes". Information Sciences. 329: 524–539. doi:10.1016/j.ins.2015.09.040. <a href="/wiki/Doi_(identifier)" target="_blank">/wiki/Doi_(identifier)</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></li>
<li id="fn:12">"Unvanish: Reconstructing Self-Destructing Data". Archived from the original on 2012-03-20. <a href="https://web.archive.org/web/20120320161926/http://z.cs.utexas.edu/users/osa/unvanish/home" target="_blank">https://web.archive.org/web/20120320161926/http://z.cs.utexas.edu/users/osa/unvanish/home</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></li>
<li id="fn:13">Gupta, Kishor Datta, et al. "Shamir's Secret Sharing for Authentication without Reconstructing Password." 2020 10th Annual Computing and Communication Workshop and Conference (CCWC). IEEE, 2020. <a href="#fnref:13" class="footnote-back-ref">↩</a></li>
</ol>

Secret sharing open-in-new

Secret sharing