Encrypted on-chain state


#1

Greetings,

I’ve read https://blog.enigma.co/expanding-enigmas-roadmap-towards-a-privacy-layer-for-the-decentralized-web-f1d6b7908251

we will support storage of computation outputs by storing the contract state encrypted on chain and sending results directly to the dApp user

I wanted to know what is the approach to manage these keys - who would be able to see the encrypted data? only the dApp user?

Would you eventually work on some secret-sharing scheme?


#2

Hi David,

the encryption of inputs and outputs will be the “mirror image of one another” using a symmetric key derivation scheme using private/public key pairs.

In the case of inputs, the dApp user can derive a key using her private key (PvtU) and the public known encryption key (PubN) of the worker node that will execute the computation, and she will submit her public key along with the computation request. When the node receives the request with the encrypted input, the node will be able to derive the symmetric encryption key using the node private key (PvtN) and the user public key (PubU), given that the following holds: PvtU * PubN = PubU * PvtN

The node will run the private computation, and then the reverse from above will happen, namely the node will encrypt the output with a key derived from the node private key and the dApp user public key, so that the user, and only the user, will be able to decrypt the result using her private key and knowing the node’s public key.


#3

Hey, thanks for the reply

What would happen if the enclave’s owner kills its instance or its CPU dies - would the data be lost?

any backups plan?

  • is there some interoperability between enclaves?

David


#4

In the upcoming Discovery release of the Enigma protocol, the nodes will maintain a state (which is a major difference with the previous docker testnet release of June 30th, 2018 in which all the contracts were stateless). That means that every secret contract will have its own state that the network will maintain. In the Discovery release all the nodes will maintain a copy of the state across all contracts. In future releases the state will be “sharded” and only maintained by groups of nodes assigned to certain contracts, that’s a future development.

So for the upcoming Discovery release, all the nodes will have a shared secret with which to encrypt the state and share the state updates. This represents a tradeoff in reduced complexity at the expense of reduced security that will be further developed in the next release with a more elaborated key management system and the sharding of states outlined above. In trying to anticipate a possible follow up question, bear in mind that every time a new node joins the network, and before it obtains those shared keys, the network verifies that the node is not malicious through the process of remote attestation verifying two things simultaneously: that the code that the node claims to be executing inside the enclave is indeed executing inside a legitimate enclave (and not code running in SGX simulation mode, which can be debugged and secrets leaked), and that the hash of that code matches the same that the Enigma distributes (meaning it does what it’s supposed to do, and nothing else like leaking secrets). With those two assurances, we can provide guarantees towards the confidentiality of the data that those enclaves handle, and the state that is maintained and shared across enclaves.

Victor


#5

One more thought as I want to make sure I answer your question: as long as the enclave is not killed or the CPU does not die before the computation is completed, the results are committed on chain and the state propagated to the network (which all should happen within a short span of time), data will not be lost. If the node goes offline after that, data is preserved. If the enclave is killed half-way through a computation or half-way through any of the other steps described above, then the economic incentives kick in, the account associated with that enclave is penalized (i.e. losing part of the stake), and eventually another enclave is assigned to compute that same task arriving at the same results that the first enclave lost.


#6

Great I see.

This represents a tradeoff in reduced complexity at the expense of reduced security that will be further developed in the next release with a more elaborated key management system and the sharding of states outlined above.

Secret sharing could be interesting - Using a distributed key generation protocol.

Do you have any idea of storing data off-chain? and just returns the hash on-chain?


#7

Yes, this is currently under consideration for future development. That’s the overall direction we are headed towards.

We would only consider such an implementation if it relied in a decentralized off-chain storage like IPFS. But we are not actively considering this at the moment.


#8

@victor I have a couple of questions about the encrypted state, if you don’t mind.

  1. This encrypted on chain state storage is different from the off chain storage in the DHT mentioned in the white paper, correct?
  2. Will secret contracts have encrypted state by default? In the Discovery release, will we be able to specify in a secret contract whether we want to store data on chain in the encrypted state or off chain in the DHT?
  3. Will encrypted state apply to user defined structs as well (both on and off chain)? i.e. if I have an arbitrary custom struct, will I be able to store this in an encrypted format in either of these locations?
  4. Will we be able to access storage on and off chain from within Enigma callable functions?

If there’s a resource or guide that answers these questions, please feel free to direct me to that.


#9

@crypto_mentions, my answers to your questions below:

1. This encrypted on chain state storage is different from the off chain storage in the DHT mentioned in the white paper, correct?

Yes, correct.

2. Will secret contracts have encrypted state by default? In the Discovery release, will we be able to specify in a secret contract whether we want to store data on chain in the encrypted state or off chain in the DHT?

Yes, all secret contracts in Discovery will have encrypted state by default.
In the Discovery release, the off-chain storage will not be implemented yet, so you will only have the option to use the on-chain storage, if needed.

3. Will encrypted state apply to user defined structs as well (both on and off chain)? i.e. if I have an arbitrary custom struct, will I be able to store this in an encrypted format in either of these locations?

Tentatively yes, given the answer to #2 above.

4. Will we be able to access storage on and off chain from within Enigma callable functions?

Tentatively yes, same as above.


#10

Thanks for the thorough reply, Victor!