Talk:Shamir Secret Snakeoil

From Bitcoin Wiki
Revision as of 18:06, 27 November 2019 by Gmaxwell (talk | contribs) (minor additions)
Jump to: navigation, search

This article should be cleaned up to remove bias. I understand Greg Maxwell is well respected in terms of his cryptography knowledge, but its clear that this article is written in a way that includes many weasel words, including in the title itself. Shamir's secret sharing algorithm is, even by Greg Maxwell's own admission here, a perfectly valid and secure algorithm. The fact that many programmers have botched the implementation is not an indictment of the algorithm itself. This page should be upgraded to be a bit more professional and unbiased, noting the pitfalls as well as the downsides in comparison to multisig alternatives, but also being clear that it is a secure tool people can use as long as they find well vetted implementations (like anything in cryptography). Fresheneesz (talk) 00:20, 25 November 2019 (UTC)

Note that the article Shamir Secret Sharing redirects to this article. I'm guessing the author added that for effect so that if someone searches Shamir Secret Sharing they can immediately see it be called snakeoil. The title isn't weasal words (which is using anonymous authority) but name calling which is legitimately useful in rhetoric (in our ecosystem see "shitcoin", "fedcoin", "scamcoin", etc). In this case the namecalling is useful to help the idea stick in people's heads (see rule 1 of how to make ideas sticky). The article does not use the argument that some programmers have botched the implementation therefore the algorithm is bad, instead the argument is that SSS itself is not a useful algorithm for storing bitcoins. Being unbiased is not an ideal to aim for; we should never be unbiased about educating people so they can avoid harming themselves. If you believe SSS is valuable you should respond to some of gmaxwell's points, such as the argument about SSS requiring the private keys to be restored in one machine, and if you have access to a secure machine you may as well just use store keys there without resorting to SSS. A multisig vs SSS section could be useful but multisig still wins hands-down, especially after schnorr gets adds to bitcoin, and even without schnorr a huge number of UTXOs today are in 2-of-3 multisig so the privacy issue isn't even that bad. Belcher (talk) 17:06, 27 November 2019 (UTC)
In fact, re about it not being about botched implementations... it even states "Errors in SSS implementations are not usually the fault of an unusual incompetence in their developers." SSS is unusually brittle, which is unsurprising when you realize that it's just a generalization of the one-time-pad from 2 of 2 (ciphertext+key) to N of M. Consider how frequently OTP is described as highly brittle and prone to errors, useful in few circumstances, and generally recommended against: E.g. 1 2 3. One can also state that correctly used OTP is a "valid" and "secure" system, but that doesn't make it useful. Most experts would immediately flag any product bragging about one time pads as likely outright insecure, or at a minimum over-hyped. This article is intending to make the same case for SSS. And as the examples show, someone who followed this heuristic would have successfully avoided several widely used insecure systems.
Other kinds of cryptography are also brittle (though not usually as bad as OTP/SSS) but they seldom have the unique combination of extremely low practical value, brittleness, and innate appeal to non-experts that result in a broad ecosystem of practically broken tools. "Snakeoil" in the traditional description is a product that is promoted as being a miracle cure to various ills to an unsophisticated consumer but which doesn't actually cure any ill that they're likely to have. And I think the article makes the case that SSS is usually snakeoil in just that sense. Implemented perfectly it is still usually pointless or nearly pointless: it doesn't cure an ill that the user has. Worse, it's usually not implemented perfectly so it has often made user's security much worse in practice. These three factors (uselessness, brittleness, and naieve-appeal) aren't independent, but feed off each other: Expert practitioners who would be more likely to implement correctly don't bother because it's low value and not worth the effort, while people paying casual attention can easily get seduced by the ritual aspects and fail to pay attention to the brittleness and as a result feel a lot more secure than they actually are. In security it's not just important to have the right amount of security but it's also important that you feel exactly as secure as you are, no more no less. In Bitcoin in particular, multisig actually offers essentially all of the security advantages commonly ascribed to SSS but without the usability flaws that make SSS so often useless, while also being generally less brittle (at least for ordinary CMS multisig).--Gmaxwell (talk) 18:03, 27 November 2019 (UTC)