Any reason to use Shamir given faster XOR threshold secret sharing algos? TL;DR:

Is the Kurihara algorithm really what it purports to be (dramatically faster but equally secure replacement for Shamir Secret Sharing)?

https://scholar.google.com/scholar?q=kurihara+secret+sharing

Background

Shamir's secret sharing algorithm has the desirable properties of information theoretic security (possessing shares fewer than the threshold is no better than random data) and minimal storage (each distributed share is the same size as the original secret).  However, it's very slow to compute, to the point that when dispersing a large file with Shamir you would typically use ordinary symmetric encryption for the file at large and protect only the symmetric key with Shamir.

As of around the year 2007 industrial researchers in Japan (Kurihara et alia at KDDI and others at Toshiba) and academics in China (Chunli et alia) have published papers showing how to use random numbers with simple XOR operations to accomplish the same level of information theoretic security and minimal storage, with performance hundreds of times better than Shamir Secret Sharing.  Some of the algorithms offer arbitrary "(k, n)", aka "(threshold, sharecount)" flexibility, as Shamir also does.

Is there any reason to continue using Shamir versus the new XOR based threshold secret sharing algorithms?
Is the Kurihara algorithm really what it purports to be (dramatically faster but equally secure replacement for Shamir Secret Sharing)?


The algorithm being referred to is in this paper, and I believe that the speed benefits are at best marginal, if not nonexistent.

As for the speed benefits being marginal, well, normally we use secret sharing as a part of an overall algorithm achieving something else, and the time taken by the secret sharing algorithm is dominated by something else, and so the time taken doesn't really matter.

As for the speed benefits being marginal, well, that's because Shamir's method really is quite efficient; the generation of a share (once you've generated the randomess) is $k-1$ field multiplications and $k-1$ field adds; if you use the field $GF(256)$, this can be done with $2k-1$ table lookups, $k-1$ adds and $k-1$ xors.  The recombination step (once you've converted the id's into coefficients) is $k$ field multiplications and $k-1$ field adds; similarly cheap.

Now, you ask, why does the paper claim to do so much better than Shamir?  Well, that's because they were testing it against a Secret Sharing implementation that was never designed for performance.  If you look into the implementation of SSSS, you'll see that it uses the GMP bignum library to perform the operations.  Since the internal operations it uses are cheap (exclusive-or and shift left by one), the vast bulk of the time is spent in memory management (allocating and freeing memory).  Furthermore, the field multiply implementation it uses is a generic one; if one is greatly concerned with speed, one could do better by optimizing for a specific field size (as I mentioned, a moderate sized field such as $GF(256)$ can be done quite fast using log and antilog tables).

Now, to be clear, I'm not saying that the SSSS implementation is bad; what I am saying that performance wasn't very high on the developers list.  However, if speed is considered important, one can do quite a lot better.

As for your overall question, 'given that there are alternatives to Shamir, why do people generally stick with it?', well, I suspect that it's a combination of Shamir is good enough (a good implementation should run in a time that's competitive to Kulihara, and in any case, an I mentioned, we generally don't care), and that Shamir was the first (and people tend to stick with what's first - remember, people are still using RSA, even though we have better alternatives available).