Talk:Secret sharing

message: "Seems too minor for its own article.  Completely obscure to the layman." GCW
: This 1998 bibliography includes 216 academic papers on the subject. — Matt Crypto 15:43, 13 Dec 2004 (UTC)
replies: text:  It's only obscure to someone who's not interested in cryptography. To anyone -- even a "layman" who wants to understand crypto (like myself), this is obviously a key concept. --Kadin2048 20:47, 20 March 2007 (UTC)
replies: text:  Crazy comment to make. If it ever comes up please receive my vote to Keep.  —Preceding unsigned comment added by 86.146.50.27 (talk) 23:51, 6 October 2009 (UTC)
replies: text: I presume that the comment was true from the standpoint of GCW who simply said it (the article) was obscure and "seems" too minor.  The implication is that the article needs to be clarified so it is clear to an (interested) layman why it is indeed important.  Hopefully it has improved since then, as discussed in the next section.  ★NealMcB★ (talk) 20:27, 13 June 2011 (UTC)
thread_title: too minor, too obscure

message: Just came across this comment. It's understandably obscure to the layman, for which apologies are perhaps due as a perfect article would make clear all. In the case of this subject, I think that there isn't a chance of being that clear. Not in the real world and with real people writing in real langauges.
The article as it stands is superb. Better than that! It's an example of what I hope the crypto coverage in WP will eventually uniformly be; though I trust the less technical articles will be more understandable to the layman. This is regrettably a sort of 'inside baseball' for the non crypto oriented, but let me hasten to assure them that the technique(s) here is(are) of critical importance in real crypto system design. 
Superb work all. Highest congratulations.
ww 19:11, 17 Apr 2004 (UTC)
replies: text: Note that the article was a little different back at the time of thie above comment; Back then it was:  — Matt 19:18, 17 Apr 2004 (UTC)
replies: text: Matt, I looked, I understand that. But still... This is good work, albeit on an obscure topic. Think how far this is from what might have been expected! ww 19:29, 17 Apr 2004 (UTC)
thread_title: really good!

message: Good article, easy readable to me, but I am also pretty much into crypto stuff. Some comments:
"The dealer gives a secret to the players, but only when specific conditions are fulfilled."
This is rather unprecise. In literature, we call it that only a "qualified subset of players" can reconstruct a sharing. This is one of my main critism at the article: It only focuses on threshold shemes, which means that a subset of players is qualified if it has size at least t.  However, the principle of secret sharing allows more general structures (see my reference).
"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. Tal Rabin and Michael Ben-Or devised a multiparty computing (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, ..." 
This is very inprecise. What means "conventionally"? It sounds like general MPC is needed to get a VSS. It is the other way round: VSS is a neccessary building block for MPC and nothing unconvential happens during the VSS, it is even possible to use the simple Shamir secret sharing and do error correction during reconstruction. (However, if the dealer can be corrupted too, it must be verified that the ditributed shares lie on a degree-t polynomial.)
Side note: (information theoretical secure) VSS and MPC are also possible for t<n/2 if there is additional a broadcast channel available. Of course a seperate article on MPC would be nice.
Reference: Secure Multi-Party Computation Made Simple
:Sounds like you have some good contributions to make. Be Bold in making them! Lunkwill 23:59, 12 Feb 2005 (UTC)
replies: text: Same thing User:Lunkwill just said — thanks (of course) for reviewing the article, and if you've got the time to fix some of the issues you've identified, it would be most welcome. — Matt Crypto 00:09, 13 Feb 2005 (UTC)
thread_title: good but..

message: Well it doesn't seem to make sense to comment on all 73 articles on the peer review page, so I will comment here. Good article. A few points: 1) The lead should tell why this is important. Just summarize a bit from 'uses and applications' as simply worded as possible. 2) There should ideally be no one or two sentence paragraphs in the article. They are spots that either need to be expanded to stand on their own or merged with similar material. 3) Why is trivial secret sharing not good enough? Seems fine to me from what the description says. 4) Is the verifiable secret sharing the same thing as Byzantine fault tolerance or just similar? In either case it could stand to be compared there. 5) The limitations section second part says random bits are required. However it doesn't prove that very well since the sentence "This information cannot be the secret, so it must be random." seems to be a non sequitur. The information could be arbitrary and not be secret either I would think. 6)  I corrected a fact in the uses and applications section. Please make verify my fix. - Taxman 21:36, Mar 2, 2005 (UTC)
: Thanks for looking this one over! Re: 1) Agreed. It would also be nice to add some examples, not just of what secret sharing could be used for, but some prominent examples of what it is used for...that is, have any of these ideas been implemented in actual systems? 2) Yes. I think they can be expanded, except "Trivial secret sharing", which might be better merged into another section. 3) I think the problem is that it requires all n out of n shares. Such schemes aren't very robust in practice: if one shareholder gets run over by a bus, the secret is lost. Being able to specify t out of n is a nice property that makes these schemes more attractive in practice -- I'll add this. 4) Similar, I guess: I think the relationship is that "Verifiable Secret Sharing" is secret sharing with Byzantine fault tolerance; there can be other applications which need Byzantine fault tolerance, such as decision-making. 5) I don't think it's worded very clearly at all. I'll try and do some reading on this and see if I can put it more precisely. 6) Looks good. — Matt Crypto 17:39, 3 Mar 2005 (UTC)
thread_title: Comments from peer review

message: Could I get more details on this "silver fish attack"?
This sounds interesting.
(And why did it need "secret sharing" properties, rather than merely RAID-like reconstruction properties?).
--70.130.45.233 07:33, 22 September 2007 (UTC)
thread_title:  Silver Fish 

message: I have just modified the lead to make it flexible enough to discuss secret sharing schemes which are not threshold schemes (that is, multi-level schemes generally). I realize that most applications of the concept used in cs are of the threshold variety, but the article should not be limited to just these. Bill Cherowitzo  (talk) 19:06, 8 August 2012 (UTC)
thread_title:  Threshold schemes 

message: This section uses the term "secure" to mean what the general literature in this area calls perfect security. It then gives an example which does not have this property. If this is an attempt to clarify the concept, I think it fails to achieve its goal because there is no corresponding example that does have the property. This poorly constructed section can lead to confusion. For instance, a recent IP editor added a confused statement about how this non-secure system could be adjusted to have any desired level of security. I reverted that edit because it was simply wrong (but I was too polite to say so in the edit summary). The editor came back with a correct statement, but one which was clearly out of place in this section. It is something that might be added to the sections on Computationally secure sharing schemes or Limitations of secret sharing schemes. I slapped a  tag on this for two reasons. Firstly, to indicate to the editor that you can't just make up stuff to put on the page, it has to have some reliable references that can be quoted and secondly, the current list of references is heavily weighted towards primary sources, and some good secondary sources are needed, especially some from the more computational (practical?) side of the subject. I would like to see a simple example of a perfectly secure scheme in this section and perhaps a section title change. If no one can come up with a better idea, I do have a geometric example that will work. Bill Cherowitzo  (talk) 17:47, 22 October 2012 (UTC)
thread_title:  The example section 

message: I think its a error in the article about the three hyperplanes.
Logically, if you know WHICH coordinate is being used as a secret, knowledge of a share can theoretically rule out all "invalid" values of x,y,z (those that are not placed on a plane)
Using 2 planes, will give a function, given any coordinate, will give the other 2 coordinates.
This will also limit the brute force space since some values will be completely out of range for some coordinates (eg values are negative, or exceeding the bit amount for a decryption key).
The scheme can be secured by simply not conveying which coordinate is the one used as secret. After obtaining all three shares in the scheme, the usage process simply has to input one coordinate after each in the validation function (can be a logon, can be a decryption process, missile launch control, or whatever secret being secured) and simply trial and error until the correct coordinate is reached.
Sebastiannielsen (talk) 22:37, 13 June 2013 (UTC)
replies: text: I do not follow your reasoning. The shares in the Blakley scheme are equations of planes passing through the point (x,y,z). Given any share, a triple not in that plane is "invalid" - you do not need to know which coordinate contains the secret to prune these values, and knowing it does not prune any additional triples. The calculations involved are generally done mod p for some prime p. This prime is chosen to be large enough to make any brute force attack infeasible and there will be no coordinate values that are "out of range". While there are protocol errors that have to be avoided when setting up the system, making which coordinate the secret lies in public, is not one of them. Bill Cherowitzo  (talk) 04:52, 14 June 2013 (UTC)
thread_title:  About the hyperplanes 

message: Meanwhile in Japan... in 2007 and 2008 Kurihara et alia published papers on the subject of secret sharing algorithms with the same characteristics as Shamir (data size times "n", perfect secrecy below the threshold of shares), but with drastically faster performance, like a few orders of magnitude better.  Is this something that the article should cover?  See https://www.google.com/search?q=kurihara+secret+sharing Wookian (talk) 21:48, 4 August 2015 (UTC)
thread_title:  Kurihara XOR based approach