I would like to hear your opinion on my idea to share a proof of a secret message in a contract, that users can verify later in a second phase when the message will be revealed.

If the message is a random piece of text, you could easily store a hash of the message as a proof and when the secret message is revealed, compare both hashes to verify its validity. However if the message is just a word or a number that can be easily included in a dictionary, you can have as well a collection of hashes indexed for every word/number in the dictionary and you will be able to find the corresponding secret message. The proposed solution will use symmetric cryptography (Fernet) to encrypt off-the-chain the message and store a hash of the encrypted message in the contract.

On a different phase when the secret message will be reveled, the full encrypted message and its secret key will be shared as well in order to verify the initial proof provided. Decrypting the message off-the-chain and comparing its hash to the initial proof will be enough to verify it.

Is there any other way am I missing?

  • 1
    This question seems unrelated to Ethereum, perhaps crypto.stackexchange.com is better suited for it. Also you might want to consider a standard protocol like ECIES to share messages. – Ismael Jan 16 '20 at 13:55
  • It's a contract common problem that need a common design pattern to be addressed – Veilkrand Jan 17 '20 at 3:22

If you're worried about someone bruteforcing (or rainbow tables as your question suggests) the input you can use something called Salts ( https://en.wikipedia.org/wiki/Salt_(cryptography) ). That way there's no way to bruteforce the input if the salt is kept secret as well. People can't change their secret upon will without spending a lot of effort in finding a correct salt which together produce the right encrypted message (or hash).

You also mention that you'll use symmetric encryption. I don't see any reason not to use asymmetric encryption which is more secure in general. Everyone just needs to agree on the encryption algorithm, keep salt and secret hidden and reveal them when needed.

Anyway this question would maybe be better suited in some security forum.

  • I'm also not an expert on cryptography but sharing a secret with just with a salted hash is an extremely weak encryption method. I don't see how asymmetric encryption will make this process more safe or less complex than the suggested method on my question. – Veilkrand Jan 15 '20 at 13:15
  • It all depends on your needs - no need to overkill. Hashing is not encryption and there's nothing wrong with hashing per se. Hashing with a salt is a lot better than simple hashing if the input can be guessed/bruteforced. – Lauri Peltonen Jan 15 '20 at 13:31
  • Well I personally feel safer in most of the cases to share a hash of a encrypted secret than just a plain text with some random salt :) – Veilkrand Jan 15 '20 at 13:35
  • I'm not sure if you misunderstood me: salt is useless without encryption/hashing. So of course you shouldn't share plaintext – Lauri Peltonen Jan 15 '20 at 13:48
  • Sorry to keep this conversation open. But again your proposed solution using a hash and a salt doesn't provide a verificable secret mechanism. There's no way to verify in an early first phase the secret without the salt. Thus when the secret is revealed you would be able to spoof the salt to fit your unverified secret – Veilkrand Jan 24 '20 at 2:25

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.