slip-0039: it's SSS not SSSS

parent 63ab98b7
...@@ -24,7 +24,7 @@ Each SLIP should provide a concise technical specification of the feature and a ...@@ -24,7 +24,7 @@ Each SLIP should provide a concise technical specification of the feature and a
| [SLIP-0017](slip-0017.md) | Elliptic Curve Diffie-Hellman using deterministic hierarchy | Standard | Draft | | [SLIP-0017](slip-0017.md) | Elliptic Curve Diffie-Hellman using deterministic hierarchy | Standard | Draft |
| [SLIP-0018](slip-0018.md) | reserved | Standard | Draft | | [SLIP-0018](slip-0018.md) | reserved | Standard | Draft |
| [SLIP-0032](slip-0032.md) | Extended serialization format for BIP-32 wallets | Standard | Draft | | [SLIP-0032](slip-0032.md) | Extended serialization format for BIP-32 wallets | Standard | Draft |
| [SLIP-0039](slip-0039.md) | Shamir's Secret-Sharing Scheme for Mnemonic Codes | Standard | Draft | | [SLIP-0039](slip-0039.md) | Shamir's Secret-Sharing for Mnemonic Codes | Standard | Draft |
| [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044 | Standard | Draft | | [SLIP-0044](slip-0044.md) | Registered coin types for BIP-0044 | Standard | Draft |
| [SLIP-0048](slip-0048.md) | Deterministic key hierarchy for Graphene-based networks | Informational | Draft | | [SLIP-0048](slip-0048.md) | Deterministic key hierarchy for Graphene-based networks | Informational | Draft |
| [SLIP-0173](slip-0173.md) | Registered human-readable parts for BIP-0173 | Standard | Draft | | [SLIP-0173](slip-0173.md) | Registered human-readable parts for BIP-0173 | Standard | Draft |
......
# SLIP-0039 : Shamir's Secret-Sharing Scheme for Mnemonic Codes # SLIP-0039 : Shamir's Secret-Sharing for Mnemonic Codes
``` ```
Number: SLIP-0039 Number: SLIP-0039
Title: Shamir's Secret-Sharing Scheme for Mnemonic Codes Title: Shamir's Secret-Sharing for Mnemonic Codes
Type: Standard Type: Standard
Status: Draft Status: Draft
Authors: Pavol Rusnak <stick@satoshilabs.com> Authors: Pavol Rusnak <stick@satoshilabs.com>
...@@ -15,19 +15,19 @@ Created: 2017-12-18 ...@@ -15,19 +15,19 @@ Created: 2017-12-18
## Abstract ## Abstract
This SLIP describes a standard and interoperable implementation of Shamir's secret-sharing scheme (SSSS), which is a form of secret sharing, where a secret is divided into parts, giving each participant its own unique part, where some of the parts or all of them are needed in order to reconstruct the secret. This SLIP describes a standard and interoperable implementation of Shamir's secret-sharing (SSS), which is a form of secret sharing, where a secret is divided into parts, giving each participant its own unique part, where some of the parts or all of them are needed in order to reconstruct the secret.
## Motivation ## Motivation
Preservation of digital assets is generally important and it is especially important in the case of decentralized payments systems such as Bitcoin, where there is no recourse in the case of loss of an asset. The usual approach to protecting digital assets is redundant backups, but when the asset itself is a valuable capability, there is a substantial risk of the backup holder absconding with the asset. Shamir's secret-sharing scheme provides a better mechanism for replicating secrets without giving the capability to the backup holder. Preservation of digital assets is generally important and it is especially important in the case of decentralized payments systems such as Bitcoin, where there is no recourse in the case of loss of an asset. The usual approach to protecting digital assets is redundant backups, but when the asset itself is a valuable capability, there is a substantial risk of the backup holder absconding with the asset. Shamir's secret-sharing provides a better mechanism for replicating secrets without giving the capability to the backup holder.
However, SSSS is not standardized today, making it possible for a future secret recovery to be put in jeopardy if the tools have changed. Therefore, we propose standardizing SSSS so that SLIP-0039 compatible implementations will be interoperable. However, SSS is not standardized today, making it possible for a future secret recovery to be put in jeopardy if the tools have changed. Therefore, we propose standardizing SSS so that SLIP-0039 compatible implementations will be interoperable.
## Shamir's secret-sharing scheme ## Shamir's secret-sharing
Shamir's secret-sharing scheme (SSSS) is a cryptographic mechanism how to divide a secret into `N` unique parts, where `M` of them are required to reconstruct the secret. First, a polynomial of `N-1` degree is constructed and each party is given a corresponding point - a non-zero integer input to the polynomial and the corresponding output. Shamir's secret-sharing (SSS) is a cryptographic mechanism how to divide a secret into `N` unique parts, where `M` of them are required to reconstruct the secret. First, a polynomial of `N-1` degree is constructed and each party is given a corresponding point - a non-zero integer input to the polynomial and the corresponding output.
In case sufficient `M` values are provided the points exactly define the polynomial. The polynomial's value of `f(0) = S` corresponds to the master secret. You may read more on SSSS on [Wikipedia](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing). In case sufficient `M` values are provided the points exactly define the polynomial. The polynomial's value of `f(0) = S` corresponds to the master secret. You may read more on SSS on [Wikipedia](https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing).
![curve](slip-0039/curve.png) ![curve](slip-0039/curve.png)
...@@ -40,10 +40,10 @@ The value to be encoded as the master secret must be a multiple of 8 bits. This ...@@ -40,10 +40,10 @@ The value to be encoded as the master secret must be a multiple of 8 bits. This
From this value, every byte is mapped to the specified field in a little-endian fashion (i.e. the first bit maps to `a_7`, the last bit maps to `a_0`). For each such field element, `N`-share field elements are generated and mapped back to bytes. Each participating party receives the following data: From this value, every byte is mapped to the specified field in a little-endian fashion (i.e. the first bit maps to `a_7`, the last bit maps to `a_0`). For each such field element, `N`-share field elements are generated and mapped back to bytes. Each participating party receives the following data:
| 5-bit index | 5-bit M threshold | variable-bit SSSS part | 16-bit checksum | | 5-bit index | 5-bit M threshold | variable-bit SSS part | 16-bit checksum |
|-------------|-------------------|------------------------|-----------------| |-------------|-------------------|-----------------------|-----------------|
The index corresponds to the SSSS part's `x` value (see the diagram above) and the SSSS part is the corresponding `y` value. The index corresponds to the SSS part's `x` value (see the diagram above) and the SSS part is the corresponding `y` value.
Index and threshold are encoding using the following scheme (convert from bits to decimal and add 1): Index and threshold are encoding using the following scheme (convert from bits to decimal and add 1):
...@@ -57,12 +57,12 @@ Index and threshold are encoding using the following scheme (convert from bits t ...@@ -57,12 +57,12 @@ Index and threshold are encoding using the following scheme (convert from bits t
| 11110 | 31 | | 11110 | 31 |
| 11111 | 32 | | 11111 | 32 |
The checksum field is a checksum of the whole share (i.e. index, threshold, SSSS part). The checksum field is a checksum of the whole share (i.e. index, threshold, SSS part).
This structure is then converted into a mnemonic passphrase by splitting it up by 10 bits which correspond as an index to the a word list containing exactly 1024 words (see below). This structure is then converted into a mnemonic passphrase by splitting it up by 10 bits which correspond as an index to the a word list containing exactly 1024 words (see below).
| master secret | SSSS part | share length | | master secret | SSS part | share length |
|---------------|-----------|------------------------| |---------------|----------|------------------------|
| 128 bits | 144 bits | 170 bits = 17 words | | 128 bits | 144 bits | 170 bits = 17 words |
| 256 bits | 272 bits | 298 bits = 30 words | | 256 bits | 272 bits | 298 bits = 30 words |
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment