Multi-Party-TSS (ECDSA-DKLs23)
Silent Shard uses
Multiparty computation (MPC) and enables a set of parties that do
not trust each other to jointly compute a secret signing key without
being constructed in one place and an ECDSA signature over their secret key shards
while not sharing them with any of the involved parties, removing single points of trust.
TSS consists of three stages:
- Distributed Key Generation (DKG),
- Distributed Signature Generation, and
- Proactive Security with Key rotation/refresh.
These functions involve cryptographic computing at the participating
nodes of the MPC quorum and exchanges of rounds of messages which
ultimately lead to the generation of a valid signature at the
requested node. These computing nodes can be any device with
sufficient computational and memory capability, including but not
limited to smartphones, server nodes, and edge devices. The basic
philosophy behind Silent Shard remains that no single device holding
the private key can be used to generate signatures and move digital
assets. The private key is shared among multiple computing nodes so
that no party has any information about the key. Then, in order to
generate a signature, the threshold number of devices run a secure
two-party computation protocol that generates the signature without
revealing anything about the parties' key shares to each other. These
devices may or may not be associated with the same person or
organization and can be any form factor. Thus, one could use this to
create a wallet, sharing the private key between one's mobile and
one's laptop, between one's mobile and a VM in the cloud, and so on.
Protocol
- Silent Shard is based on DKLs23 threshold signature scheme
- Enabled by well-chosen correlation + simple new consistency check.
- Blackbox use of UC 2-round 2P-MUL. OT-based
protocols satisfy UC, but AHE is more complicated.
- No (explicit) ZK proofs during signing or DKG; light protocol and
straightforward UC analysis.
Disclaimer
- The code does not handle network communication security.
- The state struct per request has public and private fields.
- Presignatures should be used only once.
- Proper validating of messages per round is needed.
Installation
npm install @silencelaboratories/dkls-wasm-ll-node
Important Data Objects
Party ID
Each participant of DKG or DSG is identified by party id, a small
integer range [0..N-1], where N is number of participants of some
particular protocol.
Message
A message is an opaque array of bytes with two additional properties:
from_id
and to_Id
. Caller should use from properties to route
messages to a receiver after encrypting and authenticating the message in transmit.
new Message(payload: Uint8Array, from: number, to?: number);
KeygenSession
Create a new distributed key generation session.
function dkg(n: number, t: number): Keyshare[] {
let parties: KeygenSession[] = [];
for (let i = 0; i < n; i++) {
parties.push(new KeygenSession(n, t, i));
}
return dkg_inner(parties);
}
function dkg_inner(parties: KeygenSession[]): Keyshare[] {
let msg1: Message[] = parties.map(p => p.createFirstMessage());
let msg2: Message[] = parties.flatMap((p, pid) => p.handleMessages(filterMessages(msg1, pid)));
let commitments = parties.map(p => p.calculateChainCodeCommitment());
let msg3: Message[] = parties.flatMap((p, pid) => p.handleMessages(selectMessages(msg2, pid)));
let msg4: Message[] = parties.flatMap((p, pid) => p.handleMessages(selectMessages(msg3, pid), commitments));
parties.flatMap((p, pid) => p.handleMessages(filterMessages(msg4, pid)));
return parties.map(p => p.keyshare());
}
function filterMessages(msgs: Message[], party: number): Message[] {
return msgs.filter((m) => m.from_id != party).map(m => m.clone());
}
function selectMessages(msgs: Message[], party: number): Message[] {
return msgs.filter((m) => m.to_id == party).map(m => m.clone());
}
KeygenSession
object is serializable. Use methods .toBytes()
and
.fromBytes()
.
Both Keyshare
and KeygenSession
need to be properly encrypted and authenticated
Key roation
A key rotation session is very simular to normal key generation.
let session = KeygenSession.initKeyRotation(existingKeyShare);
newKeyShare.finishKeyRotation(existingKeyShare);
SignSession
Create a sign session
function dsg(shares: Keyshare[], t: number, messageHash: Uint8Array) {
let parties: SignSession[] = [];
for(let i = 0; i < t; i++) {
parties.push(new SignSession(shares[i], "m"));
}
let msg1: Message[] = parties.map(p => p.createFirstMessage());
let msg2: Message[] = parties.flatMap((p, pid) => p.handleMessages(filterMessages(msg1, pid)));
let msg3: Message[] = parties.flatMap((p, pid) => p.handleMessages(selectMessages(msg2, pid)));
parties.flatMap((p, pid) => p.handleMessages(selectMessages(msg3, pid)));
let msg4: Message[] = parties.map(p => p.lastMessage(messageHash));
let signs = parties.map((p, pid) => p.combine(filterMessages(msg4, pid)));
return signs;
}
Memory managment
Message
object designates a memory buffer in the WASM heap. There is
not automatic memory managment and caller is responsible to call
.free()
at apropriate time.
Methods .handleMessages()
consumes passed in messages. This means
that caller have to call .free()
methods only to deallocate objects
as part of error handling.
Error handling
session.handleMessages() may throw an error. It is impossitle to
recover from the error. It is impossible to continue execition of a
protocol.
In most cases err.message only could help to debug an application.
One special case MUST be handled.
SignSession.handleMessages() could throw an error AbortProtocolAndBanParty.
In this case, the error object has property "banParty", the value is
in range [0 .. threshold-1]. Zero is valid party ID!