Encrypt Arguments and Data Stored in Smart Contracts on the Blockchain

Hi,

I’ve build this nice trivia game. You can create a game and enter trivia questions and answers.

Now I have the problem, that you can read all data publicly on-chain, here, for example, all arguments are transparent:

https://mdw.aepps.com/contracts/transactions/ct_ptREMvyDbSh1d38t4WgYgac5oLsa2v9xwYFnG7eUWR8Er5cmT

How can I hide the data that is stored? Is there a way to encrypt the data before storing and decrypt it somehow? Or what is the best practice here? As long as this is displayed my game is too transparent and everyone can just lookup the question before the game even started.

Thanks
Emin

A good practice will be separate first the data between public and private blocks. Every data your smart contract uses for computation should be public. Private parts can be the real name of the person, or any user information you want private, or GPDR mandates be private. At this point every client can create their own AES Key tied to their name/phone/etc. when calling the smartcontract, encrypt the private parts with the AES key before sending. And when retrieving the data use the same key to decrypt it. If some user wants to share their private information with other user, that user can share their AES key. One must understand, that the private part cannot be shared between players, without having the consent of the other user (Their AES Key). The AES key here is an example, it can be a token with enough entropy than can be derived into.

So just to be sure to understand you, encrypting the data before you write it into the chain or contract state is the way to go and decrypting it when calling in your opinion?

Yes, you encrypt it in the client before write it in the chain. You could query the chain about the data, and obtain the encrypted data. But it useless without the encryption key.

The other important thing is not having any type of key hard coded. In case of the clients, if you have one global key to encrypt all your users, sniffing that key from the app will means bad actors can decode everything private in the chain. The same applies to server apps.

Per user generated key means, every user will have their own key for they private data, minimizing any risk of hacking. At the same time the user can share their private data who seems fit. And the app owner will also have no access to the private data.

Forgetting that key also is inline to the right to be forgotten. Since the access to the private data will be lost forever, and the data in the chain will become trash.

I’ve implemented something that might be useful here, so I’m publishing it. More details will be posted when I have more free time.

Basic idea: Encrypted data storage + secure key exchange on-chain

Possible use-cases:

  • resell encrypted data on-chain without revealing the decryption key after the first buyer

Note: The proposed PoC uses asymmetric encryption for secure decryption key sharing. (would be generalized further so it becomes an interface for such schemes)

Best
M

The problem with that is the seller’s inability to prove that they actually encrypted a key that can decrypt the provided data. Without that proof a buyer basically has to trust the seller. Any dispute mechanism would require such a proof or either side could just lie about their part of the deal.

What are your assumptions? Do you have a trusted dealer for your game, who runs an instance of it?
Is it ok to update the on-chain state after every completed game? Lots of questions to come up with a good scheme.

1 Like