v7.0.0
Interface for rust library blsttc. Read more about this tool in the info section.
This tool was created to be interoperable with SAFE Network safe node and safe cli.
This is a prototype tool and will definitely change in incompatible ways in the future.
Do not ever use this tool for anything.
Input: Secret Key, 32 bytes or 64 hex chars, or a random key.
Output: Public Key Hex, 48 bytes or 96 hex chars.
Input: Secret Key. 32 bytes or 64 hex chars.
Input: Message. Copy and Paste from a text editor rather than typing manually is recommended here.
Output: The signature for this message will appear here, 96 bytes ie 192 hex chars.
Input: Public Key, 48 bytes or 96 hex chars.
Input: Message. Copy and Paste from a text editor rather than typing manually is recommended here.
Input: The signature for this message.
Output: Whether the signature is valid or not.
Input: Recipient Public Key, 48 bytes or 96 hex chars.
Input: Message. Copy and Paste from a text editor rather than typing manually is recommended here.
Output: The encrypted version of this message for sending to the recipient.
Input: Secret Key. 32 bytes or 64 hex chars.
Input: The encrypted message.
Output: The decrypted message.
This type of key generation is useful when one person is in control of all aspects of the keys, eg a multisig wallet.
Input: Poly Hex (as per bincode serialization), or a random poly needing at least keys to sign or decrypt a message (this is the m in m-of-n). Minimum 2, maximum 10. Make a secure backup of poly if you want to derive key shares in the future.
Output: Master Secret Key Hex, 48 bytes ie 96 hex chars. Never used for anything and should never be shared, just shown here for information.
Output: Master Public Key Hex, 48 bytes ie 96 hex chars. This is used to verify a combined signature. A group of people will each individually sign a message, then those signatures will be aggregated to produce a combined signature which can be verified with this master public key.
Output: Master Commitment Hex. This is the basis of the Master Public Key and is needed for combining signature or decryption shares.
Show key shares (this is the n in m-of-n).
Output: Secret Key Shares. Each line is a secret key.
Output: Public Key Shares. Each line is the public key corresponding to the secret key on each line above.
A way to generate a group public key by coordinated action rather than a trusted dealer.
This is how a group of untrusted nodes (eg elders in a section on the SAFE network) can form a group key without giving away any individual secrets or trusting any individual participant.
Some details are not included (such as handling faulty nodes or the encryption of shares) but they can be seen in the BLS-DKG crate which this example is based on, as well as DIP-0006 which BLS-DKG is based on. There is also an example of DKG in the threshold_crypto crate.
Input: Shares Matrix - a group of nodes with at least nodes required to sign or decrypt messages (maximum 10 nodes).
Output: The group master public key used for encrypting and verifying messages. This is generated in Step 5, shown below the table, but is shown here because it's known by all participants.
Output: The group master commitment used when decrypting and signing messages. This is generated in Step 5, shown below the table, but is shown here because it's known by all participants.
Hover on a cell, the details of the relevant shares will display below the table.
Click a cell to retain the details while scrolling, click again to unlock.
Cell F3T2 should be read as "Share sent From node 3 To node 2".
Every node is responsible for generating their row of shares in the table, and combining their column of received shares.
| F1T1 | F1T2 | F1T3 | F1T4 |
| F2T1 | F2T2 | F2T3 | F2T4 |
| F3T1 | F3T2 | F3T3 | F3T4 |
| F4T1 | F4T2 | F4T3 | F4T4 |
Step 1: All nodes generate their own unique secret (called a BivarPoly). This is used to derive the list of shares for the other nodes, shown in Step 2.
The value shown below is the public portion of node 0's BivarPoly. The public portion is shared to all nodes and combined into the group master public key in Step 5.
Step 2: Listed below are shares node 0 will send to every other node. Only node 0 has this list of shares.
These are derived from the secret in Step 1 that only node 0 knows.
Even though only one row is currently highlighted, all rows contribute to the DKG process.
Step 3: Listed below are shares node 0 will receive from every other node. Only node 0 has this list of shares.
These are used by node 0 to generate their secret key share, shown in Step 4.
Even though only one column is currently highlighted, all columns contribute to the DKG process.
Step 4: Secret Key Share for node 0. 32 bytes ie 64 hex chars. This is created by combining the shares received by node 0 in Step 3.
Step 4b: Public Key Share for node 0. This is derived from the secret key in Step 4.
Step 5: The group master public key can be derived by any node by combining all the public portions of the BivarPolys (see Step 1 above and Bonus #2 below). The group master public key is shown above the table.
Bonus #1: The complete list of Secret Key Shares is shown below. This would never be seen in real life since each node derives their own secret key from information sent to it by other nodes (see Step 4). But it's handy to have this list here for using elsewhere in this tool.
Bonus #2: The complete list of Public Key Shares is shown below.
Bonus #3: The complete list of BivarPoly public portions
- ie BivarPoly.commitment() -
is shown below. This list is known by all nodes, and can be combined to
generate the group master commitment and group master public key
(both shown above the table).
Bonus #4: The Master Secret Key Poly is shown below. This would never be seen in real life since no node has all the secrets needed to generate it. But it's handy for using elsewhere in this tool, such as the input for Simple Threshold Keys.
Input: Secret Key Shares. There must be at least m secret keys
of an m-of-n group to be able to sign the message.
The keys do not need to be sequential or in any particular order.
The format of each line should match those generated in
Simple Threshold Keys or DKG, ie
shareIndex:hexEncodedSecretKey.
Input: Master Commitment. This can be found in Simple Threshold Keys or DKG and should be known by all nodes in the group.
Input: Message. Copy and Paste from a text editor rather than typing manually is recommended here.
Output: Signature Shares. These are combined into the group signature shown below.
Output: Signature. This can be used with the Group Master Public Key and the message to verify the message was signed by at least m-of-n members of the group. If less than m signatures are combined the signature will be invalid. Any combination of signers will produce the same signature. This means the signature can serve as a pseudorandom number unknown to anyone until m participants agree to reveal it.
Use the master public key from simple threshold keys or DKG keys to verify the signature using the verify section.
Create a master public key using simple threshold keys or DKG keys.
Use the master public key to encrypt a message in the encrypt section.
Input: Secret Key Shares. There must be at least m secret keys
of an m-of-n group to be able to sign the message.
The keys do not need to be sequential or in any particular order.
The format of each line should match those generated in
Simple Threshold Keys or DKG, ie
shareIndex:hexEncodedSecretKey.
Input: Master Commitment. This can be found in Simple Threshold Keys or DKG and should be known by all nodes in the group.
Input: Ciphertext. This is text encrypted using the group Master Public Key. Encryption can be done in the encrypt section.
Output: Decryption Shares. These are combined into the decrypted message shown below.
Output: Message. This is created by combining the decryption shares above into the message. This can only be done when m-of-n members of the group have provided their decryption share. If less than m shares are combined the message will be invalid.
This tool is based on blsttc. That repository is a combination of the public api of threshold_crypto with the signature logic of blst.
The reason to use blst for signatures is a) improved performance and b) BBS+ signatures.
Since wasm is quite limited in the interface between javascript and rust, this tool uses a rust wrapper around blsttc which is relatively awkward, but this is just an implementation detail. Not all blsttc functions are available in the wasm or this tool.
blsttc uses curve BLS12-381.
Since it's not immediately obvious which source of randomness is used by blsttc in SecretKey::random when compiled to wasm, the tool uses javascript Crypto.getRandomValues which has known assurances around the strength of the random values generated.
You can use this tool without having to be online. In your browser, select file save-as, and save this page as a file. Double-click that file to open it in a browser on any offline computer.