10

I plan to make an app utilising Ethereum that will store private data about a user. Eventually, I want this data to be accessible by selected users.

I have seen conflicting answers & discussions on various threads on SE, reddit, and, other articles about the best way to approach this. Though here are some options I have been considering:

  1. I could encrypt with a key, and add to the blockchain, but, isn't this the equivalent of a database being hacked? The data is, of course, encrypted but it is available to the public (Vitalik suggests it is low-tech Could someone suggest why this is not a good method?). In addition, this could get expensive with a lot of transactions.

  2. Use Quorum, not 100% sure if it's suitable for my use case.

  3. Zcash may offer a private data solution (haven't fully looked into it), though I would rather keep to Ethereum if possible, may have a longer life.

  4. I could Take a similar route as lemon email: message transaction data on ethereum, encrypted data on IPFS, frontend on IPFS.

I feel that 4 (lemon email) is the best option, though, kind of feels like cheating because the data isn't then on the blockchain.

Are there any other options I should consider? Is there a better way to implement this?

Improve this question

2 Answers 2

Reset to default
6

I don't think solution number 4 is cheating. The blockchain is more of a consensus engine and not exactly a database, if you store all your data on the public blockchain it'll be pretty expensive too. Storing the bulk of the data on ipfs or swarm then just the hash in the blockchain is becoming a standard solution for Dapps to avoid high costs

Improve this answer
2
  • 1
    At the point I wrote my question, I didn't realise that what I really needed was immutability, which of course is something only a blockchain can offer. So for the private data, I will be encrypting it on the blockchain with sha3 which is very very unlikely to be de-crypted
    – joe
    Oct 24, 2017 at 17:22
  • IPFS offers immutability. Although a blockchain ledger is immutable, many things offer verifiable immutability. The term "blockchain" is not a technical term. When people refer to "blockchain" what they really mean is set of distributed components that are put together in manor to promote trust. There are variety of trade-offs when one builds something of this nature and at the end of the day it's software employing various distributed system and cryptographic academic theorems.
    – rudolph9
    Jun 30, 2019 at 19:32
3

At the time of writing my question, one thing I did not consider was the key feature of using Ethereum in the first place... Immutability. The private data I want to store also needed to be immutable. This is something that only the blockchain can offer, so, in this case, I will be going for option 1, storing the private data on-chain.

My concern was that somehow the data could be decrypted, but, it appears that I need not worry.

I will be encrypting with sha3 (well, the ethereum version 'keccak'), which even offers protection against quantum attacks so this should be more than sufficient to make any private data on-chain risk free. I can't find many non-ridiculously techy suggestions as to how long it can take to decrypt other than this article.

If the quantum correction is handled by ASICs running at a few million hashes per second (and if Vulture South's spreadsheet is right), Grover's algorithm would need about 1032 years to crack SHA-256 or SHA3-256.

I did not find an better alternative, so if anyone has a suggestion please speak up.

In addition, I did not find an answer to why Vitalik considers it low-tech and, what a suitable alternative is.

Option 2 - Quorum only seems suitable for orgs that wish to share data with each other.

Option 3 - I did not consider zcash as wanted to stick with Ethereum

Option 4 - Not suitable for me, needed the data to be immutable.

Edit: So I didn't realise sha3 offers 1 way encryption (yes I am noob). As I am new to this area, I am not sure to what algorithm would be best, so, my search continues...

Edit 2 (2018-04-30): So after trying to implement this later, I found when you add gas fees on top, prices can get pretty crazy. With the prices being unpredictable, and, very high for large amounts of data, for my purposes I have deemed the blockchain unaffordable for my use case. This doesn't mean that you shouldn't of course.. it depends on your user base & what they are willing to pay. When I last looked at prices a couple of months ago it roughly worked out as something like 64characters would cost ~£1.70 to store a 64 char hash. Which is currently what I am proceeding with.

Improve this answer
5
  • Why option 4 doesn't work for you? You can use hashes to check if data has been changed or not, so you can guarantee, that data has not been changed.
    – Igor Yalovoy
    Jun 21, 2018 at 19:11
  • I suppose at the time of writing that I was thinking that I would be using IFPS to store the hashes of the private data as an alternative to storing it on ETH blockchain. You're right, I can certainly do it that way.
    – joe
    Feb 11, 2019 at 23:00
  • FWIW there is no such thing as "1way encryption". You can use a hash algorithm - which cannot be reversed to the original data - or you can use an encryption method, which can of course be decrypted given the right keys. Hash algorithms lose the content of the original data during processing. Encryption does not lose data during processing.
    – T9b
    Apr 28, 2019 at 13:19
  • Please update the answer part "encrypting with sha3". Hashing is not encryption.
    – Arun
    May 14, 2021 at 10:48
  • If you notice on Edit1 pre 2018-04-30, I came to that realisation already...
    – joe
    Sep 28, 2021 at 15:42

Your Answer

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

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