- KEEP network
- Random Beacon
- Access Control
- Axelar Network
- Anoma Network
- Shutter network
- Litterature review
Use threshold encryption
- 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
(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.
- 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.
- first secure way of having BTC on ethereum
- 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)
- 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 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
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.
- 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
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 ?
Prevents MEV via DKG network , is already on testnet and collaborating with Snapshot & kleros to get encrypted votes.
- Focused on MEV firsts
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
- 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
- Alice wants to sell a file to their community if they pay Alice 100k
- 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
- 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)