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?

Improve this question

2 Answers 2

Reset to default
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.

Improve this answer
1
  • Would it be exposed by being able to discover the private key using both the encrypted and decrypted message, or are you assuming the private key would be sent to the contract to decrypt?
    – Origin
    Commented Mar 15, 2023 at 6:37
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.

Improve this answer
4
  • 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
    Commented Jun 30, 2017 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
    Commented Jul 1, 2017 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
    Commented Jul 4, 2017 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
    Commented Jul 4, 2017 at 21:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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