The problem NuDrop solves

NuDrop utilizes the cryptographic infra of NuCypher network and allow users to share and submit data anonymously by people such as whistleblowers and journalists to organizations such as media outlets. It provides a side-channel app on top of NuCypher which facilitates this communication.

Brief

In this app the following actors (in tandem with NuCypher terms) exist:

1. Alice = Entity wishing to fund encryption of data (say Freedom of Press foundation)
2. Enrico = Entity wishing to send encrypted data (such as a whistleblower)
3. Bob = Entity that is the intended recipient, such as Wikileaks
4. Ursula = NuCypher network
5. NuDrop = Our dApp (sidechannel facilitating this)

Benefits over Securedrop

In the long-term, NuDrop can provide the following long term benefits
and improvements over Securedrop:

1. Alice can disappear from the planet and Bob can still access the data (as long as Alice provides a long enough expiry)
2. Enrico does not need to directly upload to a Securedrop, and can instead upload encrypted data through NuDrop (as Enrico), or directly upload encrypt and upload data.
3. Alice on behalf of Enrico can later on, choose the access control and revoke it as well.
4. Alice does not need to interact with any of the Bob's in the system directly. And Bob also needs not to interact with Alice. Enricos only need the policy key and keep on writing data with it without ever having to interact.
5. Alice, Enrico and Bob only need to be aware of the IPFS address to be able to communicate, which can be facilitated via NuDrop.
6. Neither Alice nor Bob needs any NU to use the network. Only ETH is needed. Alice's ETH can only be traced to have been spent on NuCypher contracts, and will have zero trace or link to Bob. (Apart from the PolicyManager contract which is not readable as such)

Challenges I ran into

The prototyping of the project was straightforward. The hurdles I faced while building the project were mostly due to the integration of the NuCypher python lib with the frontend.

Figuring out how to not let private keys travel to the backend

Since the library expects a ethereum node capable of signing transactions, it means that it would need access to the users private keys. Infura etc don't allow signing transactions. Also, this involved writing a custom signer I had to experiment with multiple ways like using Metamask to sign the transaction in the frontend itself and sending the signed Tx back to the backend directly. Finally I ended up writing my own custom wallet UI (currently very basic) so that I can manage the signing in the UI as wallets like Metamask don't work properly with signing transactions and only allow

sign

method, which is prefixed so it can't be forwarded to the backend.

Things still pending

• I switched to using FastAPI which would reduce the pain of managing the API. Few endpoints from the Flask prototype still are being migrated at the moment.
• IPFS integration