L
Threshold
NuCypher
KEEP network
TBTC
Random Beacon
Access Control
Axelar Network
Anoma Network
Shutter network
Litterature review

L

Use threshold encryption

Comparison:

Access control rules are uploaded to each Lit protocol server
Updating requires a manual process to Lit protocol
Access rules are defined via their JSON like DSL, which limits openness

Threshold

NuCypher and Keep (described below) have merged into Threshold.

Pros:

They have good docs
They have economics already figured out - they have a "pool of nodes" they can run DKG (Setup phase), they're already permisionnless. That's a big plus. Of course we can do that as well, it just takes time. Note that their permissionless feature comes bundled with the fact that they have a token (T) that is used in other features but they are incentivized in this way.

Cons:

their API is again really Lit-like and pretty bad. There are only some set of conditions available and those are much more difficult to use than Medusa. In Medusa, an application developer simply have to implement one method and he handles the conditions himself, in anyway he wants. i.e. Threshold & Lit seems to tie together Authentication & Decryption together, which Medusa doesn't do, it simply gives decryption rights.
Same as Lit, they work by having the clients manually assemble the shares locally, so they can't have a large network, their example works with 3-5 nodes in the network.

NuCypher

(re)Encryption: It's up to the client to choose whether they use one (normal case) or multiple nodes (threshold) - there is no automatic DKG, it's actually simple secret sharing from Alice !

Client will secret share the key to some nodes and then the nodes can reencrypt to data reader given the policy associated

Operations: Nodes read events from eth and are listed on different policies

Nodes must stake and can be challenged to verify "normal operations" are performed correctly.

Incentives

Nodes put collateral wrt to the amount of policies they manage
Nodes can be challenged via fake requests

Declared Use Cases:

decentralized drop box
encrypted group chat
patient controlled health data
decentralized dgital right managements
Secret credentials management for scripts and backend applications

Personal opinion: seems awfully messy and complicated, client have to do a lot of work that could whereas using a DKG would solve many problems. Unclear how to assess security as well since the responsibility seems to be on the user. Bad choice.

KEEP network

Keep documentation

Random beacon documentation

TBTC

first secure way of having BTC on ethereum

Operations:

Client make a deposit request to the keep network
Use random beacon to create a DKG committee that holds the ECDSA (bitcoin) private key
Client send money to that public key - SPV proof from bitcoin light client
Once BTC is done, the committee mint the equivalent in tBTC
the tBTC is actually non fungible so you should redeem exactly the one that you had given (or transfer ofc)

Incentives:

Client is asked to overcollaterize on their BTC bonds - it's like a loan - because of the price fluctuation of BTC vs ETH
Nodes must stake as well depending on the size of the network -many doc here

DKG SIZE IS LIKE 3-5 NODES !!!

Random Beacon

Random beacon like dfinity where committee are chosen randomly thanks to previous group (via threshold BLS)
Many incentives protection, well documented

They also have "keeps" that hold 1Mb of encrypted data but i didn't find any doc for it

Access Control

Current: Keep threshold network currently uses the “proxy reencryption” technology where a single server is responsible for reencrypting for the recipient when asked and it never learns the private key. While at first it seems like a great solution it has one big drawback: the encryptor needs to issue a special reencryption key for each potential recipient. That means there is always an interaction needed between the recipient the encryptor and the proxy service. This forbids to have a fully fledged programmatic access control.

Future: Realizing this, they are working towards “Biotic Alice” , a “one time” DKG that will be able to encrypt the message just for the recipient when being asked by a smart contract for example, the encryptor does not need to be around. The functionality is gonna be similar to Medusa ACL but with more complex setup given they want to do one setup per encryption, and it will not allow for all use cases.

Public decryption: we also intend to use the method highlighted in drand to make public decryption much cheaper than “1decryption per ciphertext” → Medusa network will issue a single BLS signature and then the application provider can provide himself all the decryption with preprocessing so it can be checked onchain. This will be much less costly than asking the network to do a full decryption per ciphertext.

Axelar Network

https://axelar.network/

TLDR:

Cross chain communication network: pass assets from one chain to another
Cross chain transactions / query via treshold committees that hold secret key.
The consensus layer
One committee per "request" so I figure the committee size must not be really big
They really nailed this specific use case and integration for developers is impressive

Whitepaper

Anoma Network

https://anoma.network/papers/whitepaper.pdf

very advanced threshold crypto !

Private assets - zcash syle but for any assets
Front running protection via threshold decryption network
Private N party trades - not using the threshold way but a new way of execution

Can be considered a competitor because it was one application we had ?

Shutter network

Prevents MEV via DKG network , is already on testnet and collaborating with Snapshot & kleros to get encrypted votes.

Focused on MEV firsts

Litterature review

Matthew Green https://eprint.iacr.org/2005/028.pdf

Use pairings to get efficiency but a lot of GT operations though
Delegator creates one “key” per potential recipient, proxy never learns anything about the key

key difference with just threshold encryption: if colluding, the key gets leaked
they resolve also the trust assumption from first proxy reencryption paper; now there is only the problem of collusion between proxy and delegatee which can authorize new delegation rights to someone else if colluding

Generalization of above to threshold setting https://mdpi-res.com/d_attachment/electronics/electronics-10-02359/article_deploy/electronics-10-02359-v2.pdf

Each party compute a local decryption share and the whole can be recomputed by one party and published onchain
Use of lots of GT operations
Similar ? https://sci-hub.se/10.1007/978-3-030-00015-8_2 same thing it seems but better explained even

DKG without proxy rencryption

Alice creates ciphertext and encrypts towards the DKG dist key

→ Only one ciphertext to send ot smart contracts

When bob wants to read, DKG nodes re-encrypts towards Bob.

We can put encryption towards at one level above :

Alice encrypts msg to Bob , and then encrypts ciphertext towards DKG

DKG release ciphertext to bob when policy accepts and dkg can never read

Alice encrypts file to a ciphertext using symmetric key
Alice s
Alice send the
So DKG can not read and DKG delivers to Bob only when policy accepts

Simple el gamal scheme, fast to encrypt for delegator (one single encryption), fast to delegate (smart contract!)
Allows for delegator to only code the “policy access” in smart contract, and doesn’t have to deal with public keys of who is going to read it (still logged though).

no online requirement for delegator or delegatee
Allows for policy based decision rather than public key decision

Ability to get an “assembler” that assembles the shares

although we loose the ability to “proof correct decryption” -

we could do it with a snark with BLS12-377 though !
To be seen, I think it can be made with regular NIZK → Ask rosario et al about this.

!!!!!!!!!!! ability to decrypt the file if corruption happens !!!!!!!

This is where scalability comes into place: large DKG will make this practical but also inccurs higher cost for “assembler”

DKG with proxy re-encryption

is useless because delegator needs to create a “renecryption key” anyway, so the nodes are only used for computing or distributing but there is no secret that nobody knows that is useful in this context.

Threshold proxy re-encryption:

Alice creates a ciphertext for herself

WHen alice wants to re-ecnrypt to Bob (or policy accepts Bob as readers)

Alice creates a seret sharing for the selected nodes and creates “re-encryption key” from Alice→Bob
The nodes can then re-encrypt the ciphertext to bob whenever, but they can never read the ciphertext
Bob need to reconstruct final ciphertext from all “partial” decrypted ciphertext

Bob can try to collude with the threshold he can get access, but Alice should already be “ready” to know Bob

nucypher :https://raw.githubusercontent.com/nucypher/umbral-doc/master/umbral-doc.pdf

SoK : https://www.nics.uma.es/pub/papers/nunez2017proxy.pdf

More complex scheme for the delegator and the delegatee O(t) naively

Delegator needs to create the polynomial and one share for each threshold node. Needs to share it privately so can’t use “onchain” mechanism, unless one encrypts the share (in this case, it needs to be interactive since we dont know if delegatee acted dishonest or not).
delegatee needs to reconstruct the final encryption from each of the shares . This can be aggregated before and put onchain, though we loose ability to prove correct reencryption
We could have a “assembler” as well but looses ability to get proof of correct decryption

Requires long term storage from nodes to store “re-encryption keys”

The DKG solution doesn’t require any storage, it can re-encrypt “ondemand”, i.e. it is stateless with respect to the load

Requires a manual operation for each potential recipient from delegator

recipient needs to compute special polynomial to share to all “threshold nodes” for each recipient, and recipient must be known to do this (public key)
online requirement for delegator
public key of recipient must be known in advance

Goal:

Alice wants to sell a file to their community if they pay Alice 100k

Encryption:

Alice creates wrapper1 = E(csk, file) (symmetric crypto)
Alice creates encryptKey = E(dkg, contractKey) (asymmetric crypto)
Alice creates wrapper2 = E(contractKey, wrapper1)
Alice sends wrapper2 and csk to their community
Alice makes a Threshold Contract saying: IF 100k are sent, decrypt encryptKey

Decryption:

Bob sends 100k to contract, threshold contract

release contractKey = D(dkg, encryptKey)

Bob uses the contractKey to get the file

wrapper1 = D(contractKey, wrapper2)
file = D(csk, wrapper1)

Competitor Matrix

L