3

Hey there I was wondering what the best technique would be for sending encrypted data to a contract, which can later be decrypted, either by the initial user, or by the contract itself, but not anyone else.

My best guess right now is to create a key-pair using CryptoJS/Forge and encrypt it with the public key, then hold the private key safely until the message is ready to be decrypted. I'm guessing that the private key will be exposed as soon as you decrypt, so would I need to generate a new key pair for every event that requires this encryption?

I've never used CryptoJS or Forge or any browser symmetric encryptions, I was wondering how I could pull this off securely?

2

Your best guess is pretty much spot-on. If you expect the contract to do the decryption, your secret and private key will need to be exposed for it to do so. If that's acceptable, you can generate new key pairs for each secret you're storing.

If you just want to store the secret and decrypt that outside the contract, you could probably be fine with using the same encryption keys multiple times.

1

As you suggest, your contract can't decrypt without exposing the key (and the newly-decrypted plaintext) to the world. Also the rest of the world will be able to see your key before your contract does, because people will be able to get it from the transaction before it is mined.

We may be able to be more helpful if you tell us a bit more about what you're trying to achieve.

  • Ok I'd like to setup a "game" that holds encrypted information until all users have submitted a choice. The contract is then able to decrypt this information and reveal the results. Is there a way to do this without generating new keypairs every "game". Perhaps a combination of PGP + Ethereum keypairs? – ethereal Jun 30 '17 at 19:57
  • You talk about the game holding the information but if the users hold their own keys then they can also hold their own own information, no? If you want them to commit to information, have them send the hash of the information in the first round, then the plaintext in the reveal round. Your contract can recreate the hash to check that they've sent the right plaintext. – Edmund Edgar Jul 1 '17 at 2:43
  • Yaa ideally they hold their own information. What encryption algorithm would you use for this case? Or would this be doable with elliptic curve schemes like parity's encrypt_message() function or something like bitcore-lib + ECIES ? – ethereal Jul 4 '17 at 20:12
  • If users are holding their own information until they reveal then publishing it to the contract then you don't need any encryption at all. Just hash the plaintext and send the hash to the contract, then in the reveal phase send the plaintext to the contract. – Edmund Edgar Jul 4 '17 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.