You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: