stream confidentiality concepts

+1 vote
I went through the tutorial on and trying to get my head around some of the concepts to apply it in our apps.

One chain we have is for Fiat transactions, where the narration sent with a transaction is stored as data eg: Payment on invoice 1234 for services rendered, something like that. We don't want that data to be public on the explorer, so we can encrypt that with a password that is itself encrypted and stored on the chain. The app itself would be able to unencrypt that data and display it for the sender and recipient. We have regulators and others that want to be able to see the data so we can use their SSH keys to give access to the password needed to see the data.

Another chain we have is for use in Supply chain tracking. items are created in the app, and metadata added at different times and hashed/timestamped for verification. That's ok so far, because it is only hashes being stored on the chain and not real data, which is handled at the app level. But let's say we wanted to store actual data on the chain, thats where we can give some users the ability to get the encrypted password to be able to see the data, and have that happen in the app, where the creator of encrypted data would decide which groups of people would be able to see data, based on ssh keys they suppled. I still think it better to store the data elsewhere, but some clients may prefer to have it on chain...

Conceptually, does the above make sense to use stream confidentiality? Just checking if there are better ways..
asked Oct 17, 2017 by mark

1 Answer

0 votes
Yes, there both sound like sensible use cases for the stream confidentiality pattern we detailed.

In the event that you have a fixed group of participants who are permitted to read a set of items, you can do things more simply, by encrypting all items in the set with a single password that is shared with those participants.
answered Oct 17, 2017 by MultiChain