When generating shares, first the terms ak-1, ak-2, ..., a1 are picked (pseudo-)uniformly at random from GF(256). a0 is the secret we wish to split. The resulting polynomial is ak-1xk-1 + ak-2xk-2 + ... +a1x1 + a0. We then evaluate this polynomial at x = 1, 2, ..., n to generate n shares. Observe that if we know k and n already, it is possible to select k - 1 terms, and to evaluate the polynomial ak-1xk-1 + ak-2xk-2 + ... +a1x1 at x = 1, 2, ..., n. Thus we have done the bulk of the computational work before even receiving a secret, and to "finalize" the shares we need only perform n XOR operations (addition in GF(256)). Of course, signing cannot start until the shares are "finalized."
Imagine a user application where the user is first asked to define k and n. While the user is then entering the secret--typing/pasting text, selecting file(s), etc.--the share generation is being mostly completed. The time difference would be user-perceivable for large k and n.
Imagine a network application that frequently splits and distributes secrets. It waits on some other process for a new secret to become available, and then splits it and sends it to a number of other nodes/ parties. If it is able to mostly precompute the shares before receiving a secret, this could cut down signficantly on system latency, especially as n and k grow.
When generating shares, first the terms ak-1, ak-2, ..., a1 are picked (pseudo-)uniformly at random from GF(256). a0 is the secret we wish to split. The resulting polynomial is ak-1xk-1 + ak-2xk-2 + ... +a1x1 + a0. We then evaluate this polynomial at x = 1, 2, ..., n to generate n shares. Observe that if we know k and n already, it is possible to select k - 1 terms, and to evaluate the polynomial ak-1xk-1 + ak-2xk-2 + ... +a1x1 at x = 1, 2, ..., n. Thus we have done the bulk of the computational work before even receiving a secret, and to "finalize" the shares we need only perform n XOR operations (addition in GF(256)). Of course, signing cannot start until the shares are "finalized."
Imagine a user application where the user is first asked to define k and n. While the user is then entering the secret--typing/pasting text, selecting file(s), etc.--the share generation is being mostly completed. The time difference would be user-perceivable for large k and n.
Imagine a network application that frequently splits and distributes secrets. It waits on some other process for a new secret to become available, and then splits it and sends it to a number of other nodes/ parties. If it is able to mostly precompute the shares before receiving a secret, this could cut down signficantly on system latency, especially as n and k grow.