]>
Threshold Secret Sharing
Cisco Systems, Inc.510 McCarthy Blvd.MilpitasCA95035US(408) 525 8651mcgrew@cisco.comhttp://www.mindspring.com/~dmcgrew/dam.htm praveenpatnala@yahoo.com
General
Cryptography
Threshold secret sharing (TSS) provides a way to generate N
shares from a value, so that any M of those shares can be used
to reconstruct the original value, but any M-1 shares provide
no information about that value. This method can provide
shared access control on key material and other secrets that
must be strongly protected.
This note defines a threshold secret sharing method based on
polynomial interpolation in GF(256) and a format for the
storage and transmission of shares. It also provides usage
guidance, describes how to test an implementation, and
supplies test cases.
Threshold secret sharing (TSS) provides a way to generate N shares
from a value, so that any M of those shares can be used to
reconstruct the original value, but any M-1 shares provide no
information about that value. This method does not rely on any
assumptions about the complexity of solving a particular
computational problem (such as factoring); it is
information-theoretically secure. Each share is slightly longer than
the original secret.
In the context of secret sharing, the word "share" means a part of
something, and "sharing" means the act of breaking up into parts.
Readers may be confused if they think of "sharing" as meaning "giving
to or posessing with others".
TSS is especially useful whenever there is a need to ensure the
availability of a secret, yet there is a simultaneous need to reduce
the risk of compromise of the secret. By dividing the secret into
multiple shares, and distributing each share to a different trusted
entity, TSS reduces that risk while providing for the availability of
the secret. At the time that the secret is divided into shares, the
threshold defining a number of shares that are needed to reconstruct
the secret is set.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
A threshold secret sharing system provides two operations: one that
creates a set of shares given a secret, and one that reconstructs the
secret, given a set of shares. This section defines the inputs and
ouputs of these operations. The following sections describe the
details of TSS based on a polynomial interpolation in GF(256).
This operation takes an octet string S, whose length is L octets,
and a threshold parameter M, and generates a set of N shares, any M
of which can be used to reconstruct the secret.
The secret S is treated as an unstructured sequence of octets. It
is not expected to be null-terminated. The number of octets in the
secret may be anywhere from zero up to TSS_MAX_SECRET_LENGTH.
The threshold parameter M is the number of shares that will be needed to
reconstruct the secret. This value may be any number between one
and 255.
The number of shares N that will be generated MUST be
between the threshold value M and 255, inclusive. The upper limit
is particular to the TSS algorithm specified in this document.
If the operation could not be completed successfully, then an error
code should be returned.
The reconstruct operation reconstructs the secret from a set shares.
The number of shares N must be provided as a parameter.
The only other parameter is the list of shares themselves.
The shares should be treated as unstructured octet strings.
If the operation could be completed, then the secret value
will be returned.
If the operation could not be completed successfully, then an error
code should be returned.
A finite field is a set of elements with associated addition,
multiplication, subtraction, and division operations. Each of those
operations acts on elements in the field, and returns an element in
the field. This specification uses the field GF(256), and each
element is represented as a single octet. There are many possible
ways to represent a finite field; below we define the field arithmetic
operations as having inputs and outputs that are octets. This fixes a
particular representation, without explicitly defining it, and it
avoids the issue of the bit-representation of octets.
The elements of the field GF(256) are represented as octets. In the
following, each octet is represented as a hexadecimal number with a leading
"0x", as in ANSI/ISO C.
The
representation of the finite field that we use is defined in terms of
the addition, subtraction, multiplication, and division operations.
We define these operations as taking two octets as input and returning
a single octet as output. These operations are defined in terms of
two tables, the EXP table () and the LOG table
(), which define the exponential function and
the logarithmic function, respectively. The ith element of these
tables are denoted as EXP[i] and LOG[i].
The addition operation returns the bitwise exclusive-or of its operands.
The subtraction operation is identical, because the field has character two.
The multiplication operation takes two elements X and Y as input and
proceeds as follows. If either X or Y is equal to 0x00, then the
operation returns 0x00. Otherwise, the value EXP[ LOG[X] + LOG[Y] modulo
255] is returned.
The division operation takes a dividend X and a divisor Y as input and
computes X divided by Y as follows. If X is equal to 0x00, then the
operation returns 0x00. If Y is equal to 0x00, then the input is invalid, and
an error condition occurs. Otherwise, the value EXP[ LOG[X] - LOG[Y] modulo
255] is returned.
We first define how to share a single octet.
The function f takes as input a single octet X and an array A
of D+1 octets, and returns a single octet. It is defined as
To create N shares from a secret, with a threshold of M, the following
procedure, or any equivalent method, is used:
Each share is initialized to the empty (zero-length) octet string.
For each share, a distinct x-value is generated. Each x-value is an octet
other than the all-zero octet. All of the x-values used during a share
generation process MUST be distinct.
For each share, the x-value associated with that share is prepended
to the share.
For each octet of the secret, the following steps are performed.
An array A of M+1 octets is created, in which the array element
A[0] contains the octet of the secret, and the array elements A[1],
..., A[M] contain octets that are selected independently and
uniformly at random. For each share, the value of f(X,A) is
computed, where X is the x-value of the share, and the resulting
octet is appended to the share.
After the procedure is done, each share contains one more octet
than does the secret. The share format can be illustrated as
where X is the x-value of the share, and A, B, and C are arrays of M+1
octets; A[0] is equal to the first octet of the secret, B[0] is equal
to the second octet of the secret, and so on.
We denote the ith Lagrange function as L_i. This
function takes as input a single octet X,
and an array U of M octets, and is defined as
Here the product runs over all of the values of j from 0 to M,
excluding the value i.
We denote the interpolation function as I. This function takes as
input a single octet Z, two arrays U and V, each consisting of M
octets, and returns a single octet; it is defined as
To reconstruct a secret from M shares, the following
procedure, or any equivalent method, is used:
If the shares are not equal length, then the input
is inconsistent. An error should be reported,
and processing must halt.
The output string is initialized to the empty (zero-length)
octet string.
The octet array U is formed by setting U[i] equal to
the first octet of the ith share. (Note that the
ordering of the shares is arbitrary, but must
be consistent throughout this algorithm.)
The initial octet is stripped from each share.
If any two elements of the array U have the same value,
then an error condition has occurred; this fact should
be reported, then the procedure must halt.
For each octet of the shares, the following steps are performed.
An array V of M+1 octets is created, in which the array element
V[i] contains the octet from the ith share.
The value of I(0x00, U, V) is computed, then appended
to the output string.
The output string is returned.
After the procedure is done, the string that is returned contains one
fewer octet than does the secret.
A robust TSS system, or RTSS, is one that provides security even
when one or more of the shares that are provided
to the reconstruction algorithm may be crafted
by a malicious adversary. In addition, an RTSS system
will detect unintentional corruption of the shares.
We provide robustness by adding a pre-processing step to the
TSS share generation step, and a post-processing step
to the TSS secret reconstruction step. The pre-processing
consists of taking the secret S, then appending a hash
H(S) to it. The post-processing step consists of
verifying that the reconstructed secret has the form
S || H(S), where the symbol || denotes the concatenation
operation.
An RTSS system can perform an additional operation that verifies
the validity of a set of shares. This operation has
the same inputs as the Reconstruct operation. Its output
consists of an indication whether or not the secret could
be reconstructed, but the secret itself is not returned.
This operation may be useful in a situation in where the availability
of a secret must be verified, for example, as part of an audit.
We use a data format with the following fields, in order:
This field contains a variable number of octets.
It identifies the secret with which a share is associated.
When a secret is reconstructed, each of the shares used
as input should have the same value identifier.
This field contains a single octet.
This field contains a single octet.
This field contains a single octet.
This field contains a single octet.
This field is four octets long.
This field is a single octet in length.
It contains the finite field element that
is used as the "X" coordinate for
the share.
This field has a length that is a variable number
of octets. It contains the actual share data.
This format is illustrated in .
TSS and RTSS are suitable for the protection of long-term key
material. In such applications, it is highly desirable to provide
protection against the accidental corruption of the shares.
This section defines data formats that can be used
to protect shares. These formats are optional extensions
to the basic TSS and RTSS systems.
To protect against the corruption of the filesystem that is holding
the shares, a "magic number" can be used as the initial part of the
share data format. A magic number is a constant data string that is
chosen arbitrarily, but which is unlikely to appear in other contexts,
and thus can be used to recognize a data format when it appears in an
arbitrary data stream. The use of a magic number in the data format
for a share greatly simplifies the task of finding a share after
a filesystem has been corrupted.
The 8-octet magic number f628f91b52023d11 (hexadecimal) SHOULD be
used. The number was selected randomly from a uniform distribution.
To protect against data corruption in the underlying media, an
error-correcting code (ECC) can be used. An ECC system consists of an
encoding function, which maps the data to a codeword, and a decoding
function, which maps a (possibly corrupted) codeword to the data. The
simplest such code is a repetition code, in which multiple copies of
the data are stored. In this specification, all ECCs must be
systematic, that is, the data must appear as the initial bytes of the
codeword. This property allows an implementation of the ECC to avoid
the implementation of the full decoding algorithm.
We use a data format that incorporates the following fields, in order:
This field is four octets long. It contains an unsigned integer
in network byte order that denotes the type of the encoding, i.e.
the algorithm that was used during the encoding process.
This field is four octets long. It contains an unsigned integer
in network byte order that denotes the number of octets
in the Data field.
This field is four octets long. It contains an unsigned integer
in network byte order that denotes the number of octets
in the Redundancy field.
This field has a length that is a variable number of octets, which
is indicated by the Data Length field. It
contains the data that is intended to be conveyed by the code. If
no data corruption has occurred, then this field will contain the
data that was originally encoded.
This field has a length that is a variable number of octets, which
is indicated by the Reduncancy Length field. It
contains information that can be used to check whether or not
there are any errors in the Data field, and to correct some
errors that may have occurred.
This format is illustrated in .
If a code has a free parameter, the value of that parameter
MUST be inferable from the values of the Data Length
and Redundancy Length fields.
This section defines a format for a repetition code, which is a
particular error correcting code that is conceptually simple and easy
to implement.
The value of the Encoding Type field is equal to 0000001 (hexadecimal).
The Redundancy field contains R copies of the Data field, where R is
an even number.
The Redundancy Length is equal to the Data Length times R. The
value of R MAY be equal to zero, in which case no error
detection or correction is possible (but implementation is
simple). The value of R SHOULD be at least two.
For example, if the data that is encoded is equal to 68656c6c6f (hexadecimal),
then the ECF data with R=2 would be
To check the Data field for errors, that field should be compared
with each of its copies in the redundancy field.
The Repetition Code can be decoded by using majority-logic decoding.
Considering both the Data and Redundancy fields, there are R+1
(possibly corrupted) copies of the original data, where R+1 is an odd
number. The decoding process independently considers each octet of
the Data field, and the corresponding octets of the copies that appear in
the Redundancy field. That is, the ith octet of the Data, plus octets
i, L+i, 2L+i, ... , RL+i, are analyzed independent from all other
octets, where L is the value of the Data Length field. The
following algorithm is applied to these octets.
The binary representation of each octet is
considered. For each bit in that representation, if more
of the copies have a "1" in that position than have a "0"
in that position, then that position is decoded to the value "1";
otherwise, it is decoded to "0". This process is repeated
for all of the bit position. After all of the bits in the
octet have been decoded, the value of the ith octet
in the output of the decoding algorithm is computed, using
the same binary representation as before.
For example, if the data that was encoded in the previous
example was corrupted to the value
then decoding would proceed as follows. The fifth octet of the Data
field is equal to 2f, while the fifth and tenth octets of the
Redundancy field are equal to ef and 6f, respectively. Using a bit
representation with the most significant bit on the left, the octets
and the "majority" octet are as follows:
Thus the fifth octet in the output of the decoding algorithm
will be 6f.
This section summarizes the order of processing for when secret
sharing is performed using the facilities for robustness (RTSS), error
correction (ECC), and data recovery (Magic Number), and clarifies the
relationships between data formats. This processing can be viewed as
a layered model, as illustrated in . (Note that
we have not adhered to a strictly layered model, for the sake of
simplicity, since the format defined by RTSS is used after the shares
are generated.)
When RTSS is used, it is applied to the secret before the
sharing operation (and is removed from the secret after
the reconstruction operaation). The RTSS data format
MUST be used.
When ECC is used, it is applied to the RTSS data after the sharing
operation, so that the ECC Data field contains the entire RTSS Data
Format.
When a Magic Number is used, it is added after the ECC
formatting is done, and it is prepended to the Error
Correction Format.
In this implementation, the secret and the shares are octet
strings. Each octet is treated as an element of the finite field
GF(256 ). The share-generation algorithm is applied to each octet
of the secret independently. Similarly, the octets are treated
independently during the reconstruction of the secrets from the
shares.
Shamir's original description treats the secret as a large integer
modulo a large prime number. The advantages of using a vector over
GF(2^8) are that the computations are more efficient and the
encoding is simpler. Multiplication and inversion over GF(2^8) can
be done with two table lookups and two exors, using two fixed
tables of 256 bytes each. One limitation of the GF(2^8) approach
is that the number of shares that can be generated cannot be
greater than 255; this limitation is unlikely to be important in
practice, since fewer than ten shares are typically used.
The reconstruction of the secret is done using Lagrange
interpolation polynomials. This method is simple and easily
tested. For large thresholds, this method is less efficient than
an optimal method would be. However, performance is still good,
and it is expected that the reconstruction of the secret will not
be a performance-critical operation.
As with every crypto algorithm, it is essential to test an implementation
of TSS or RTSS for correctness. This section provides guidance for
such testing. Test cases are provided for known-answer tests.
The Share Index field can never be equal to zero. This property SHOULD
be tested.
There is a simple consistency test that can be run on an
implementation that uses the Lagrange form of the interpolation
polynomial. Each function L_i(X,U) as defined above
has the property that
The random source must be tested to ensure that it has
high min-entropy.
This section provides test cases that can be used to validate an
implementation. All values are in hexadecimal.
The algorithm used in the test case.
The secret value to be split into shares.
The number of shares required to reconstruct a secret.
A share index. Each test case has multiple share values, and
each share is associated with a share index.
A share value.
It is crucial for security that the source of randomness
used in the share generation process by cryptographically
strong; it MUST be suitable for generating cryptographic
keys. provides guidance on
the selection and implementation of random sources.
A TSS implementation SHOULD be tested as described in
.
The confidentiality of the shares generated by TSS should be
protected, since the exposure of too many shares will
undermine the security of the system. Note that, in this
regard, share values are more comparable to secret keys than
to ciphertext.
This document has no actions for IANA.
Thanks to Brian Weis for constructive feedback.
&rfc2119;
&rfc4086;