flex-dapps / enzypt

A p2p, end to end encrypted file selling platform utilising Ethereum and IPFS.
GNU General Public License v3.0
36 stars 11 forks source link

Prove that this is truly P2P + E2E encrypted #4

Open jgeary opened 5 years ago

jgeary commented 5 years ago

Hi, Thanks for open sourcing this. I can see that this repo doesn't cover any of the encryption / decryption. I would like to see the source of the frontend, because I'm concerned that this is not actually E2E encrypted, which in my mind would mean that only the seller and buyer are capable of seeing the unencrypted file. I'm convinced Enzypt is encrypting the files using a secret, which would mean the Enzypt team is capable of decrypting any file shared through the app. The only way I can imagine this is not the case is if you are using proxy re-encryption, which doesn't have a production-ready solution yet (the team at NuCypher are actively working on it though). The best way I know to do E2E encrypted file selling/sharing without proxy re-encryption requires the seller to have knowledge of the specific buyer(s) they intend to share it with so that the file (which is in their possession) can be specifically encrypted for each buyer. Enzypt doesn't have this requirement, which is really nice from a UX perspective, so I'd love to see how that works. And if Enzypt is just encrypting files with their own secret(s), then users should be aware of this / Enzypt shouldn't claim to be P2P or E2E encrypted.

morelazers commented 5 years ago

Hey @jgeary thanks for the question!

You're right, we're going to open source the frontend soon (after a little refactor to make it prettier). To answer your question, we don't use a common secret. The encryption key is generated client-side, and only the initialisation vector is passed to the server. This IV is then sent to any buyer, but they must also have the seller-generated key.

The seller distributes this key by way of it being appended to the URL on the client side which they receive upon successful upload. You can clearly see the key portion of the URL (it's after the second forward slash) https://enzypt.io/some-server-reference/#decryption-key. The buying client then parses that out of the URL and then only uses it to decrypt the file upon successful purchase.

We could by all means be logging this key with the frontend when people hit that URL, but we're not and you'll just have to trust us. If you don't trust us, you can use the API directly to perform the sale-arbitration, or you can host your own API and do it that way too.

What we can see, are all the hashes of both the payload and metadata files for each sale on enzypt (as well as the seller's ETH address, so if you're concerned, use a burner), but without the client-generated key we can't decrypt these things.

If I'm correct, this is "good" e2e encryption, and I'd love to know how we can make it better. I would love to chat with the NuCypher folks about how we could incorporate what they're doing to enzypt if possible.

Let me know if you have any more questions, and once we open up the frontend code I'll ping you here and close this issue.