Skip to content

Frost network

Basic idea without threshold signatures (copypasta from before)

The idea is that actors are able to share decryption keys, also there are proofs that correct keys have been shared. The system has three actors:

  • Network (can be several actors with threshold signature)
  • Data provider: encrypts the original data, sends decryption key to network
  • Data consumer: gets a decryption key from the network

The network has secret y, and public key yG = Y

Data provider view

  • Will first need to generate password (256 bits, or probably a bit less)
  • The data has to be encrypted and the encrypted data is made publicly available
  • Then will have to generate a secret key x
  • Public key xG: identifier for the secret
  • The shared secret will then be xyG (ecdh)
  • The password is encrypted with the shared secret (just xor)
  • The encrypted password and corresponding public key xG are stored by the network
  • There could be a ZK-SNARK that gives knowledge of the hash of the password, but it depends on the curve if it’s efficient
  • Data provider can forget the secret key (it shouldn’t be used again)
  • In theory could forget the password, but probably the network will have to change the key like once in a year, so it will have to be resent

Consumer view

  • First can download the encrypted data
  • Can get the corresponding encrypted password and xG from network / smart contracts
  • Will have to generate a secret key z
  • So the agreement will include xG and yG, also encrypted password and zG
  • The network will send y(xG+zG) to fulfill the agreement. There will probably have to be some way to send a reward to the network (re-encrytion)
  • The consumer will get the shared secret by: y(xG+zG) - yzG = xyG
  • Now the consumer will get the password with xor and can decrypt the downloaded data

Correctness guarantees (DLEQ proof that reencryption was correct)

Making sure that the network sends the correct result (DLEQ; discrete logarithm equality)

DLEQ basic description

  • Given points G, H
  • Send points X, Y
  • DLEQ proves that there exists x such that X = xG and Y = xH
  • In other words, G/X = H/Y
  • This is a ZK proof

Proving that re-encryption is correct

  • We have points G and xG+zG
  • Send points Y, R (Y is the previously known public key Y=yG)
  • Will prove that R = y(xG+zG)
  • So just DLEQ is enough to prove the correctness

Threshold signatures

In the network, the participants should not be able to access the password. To accomplish this, some kind of threshold signatures should be used. Assume that the network has participants 1..n. The secret of the network is y, and each participant has a share y_i. (These are generated by DKG).

Then there is some threshold t such that t participants can access the secret. So we have a set T \subseteq {1..n} such that |T| >= t. Then we have multipliers l_i such that y = \sum l_i y_i (where i \in T). The multipliers depend on the set T.

The problem now is how the participants can cooperate to generate the DLEQ proof for a given point xG+zG. DLEQ is a sigma protocol similar to Schnorr signatures, basically the only difference is that DLEQ has two points and Schnorr signatures just have one point. So it should be possible to adapt threshold protocols for Schnorr signatures to DLEQ.

One protocol is FROST https://eprint.iacr.org/2020/852.pdf. At the beginning round, the participants commit to a point pair. It should be enough to modify it so that participants commit to two point pairs. Because of the properties of DLEQ, we know that the aggregated signature is correct. In the case of DLEQ there will have to be two rounds, so the participants will have to interact with each other. The aggregator coordinates the communication, and would probably in this case also send the result to the blockchain.

Network setup

The network will have n nodes. One of the nodes is coordinator. The nodes will have to communicate with each other via secure channels. To setup the network, the nodes will have to use DKG (distributed key generation) to generate their secret shares and the public key for the network.

The network public key has to be setup in the contracts so that the network can start fulfilling the requests. After this, the coordinating node will monitor the contracts for conditions that should be fulfilled. When a condition is found, it will select t nodes and generate a DLEQ proof with them. Finally the coordinator fulfills the condition.

RPC calls

There are the following RPC calls:

  • coordinate_round1: start first round of DKG
  • coordinate_round2: start second round of DKG. Will return the network public key.
  • listen: poll the contract for conditions to fulfill, fulfill all found conditions.

RPC calls that are internal for DKG:

  • init_round1: participants commit to their secrets
  • validate_round1: send commitments to other participants. Other nodes should validate that the commitment are correct
  • make_shares: generating shares
  • set_share: send shares to other participants. When all shares are received, validate them

RPC calls that are internal for Frost:

  • crypt: encrypt message with share
  • reencrypt: coordinate threshold encryption
  • frost_round1: each node commits to secret
  • frost_round2: compute the common DLEQ challenge and make own part of the response

Interface with the contracts

The owner of the assets has to post the secret ID to the network. There should be a way to decide which agreements should be fulfilled. For this, the asset owner has to post the price for the asset. The asset buyer or some third party can submit the agreement for fulfillment by the network.