Access control through encryption: Unknown recipients

Help
,
1

Hi, first post here.
Really liking IPFS , but Iā€™m having a big issue.

One-on-one file sharing with a known recipient is not an issue. The ā€˜senderā€™ would encrypt the file with the recipient pubkey, upload it to IPFS send the hash to the recipient. The recipient could then decrypt the file with his privkey.

My issue occurs when dealing with (multiple) unknown parties.
If we combine IPFS hashes with Ethereum we could for example transfer the IPFS hash to a recipient that wants to access it once certain conditions have been met eg. a payment has been made.
These recipients are thus not known beforehand, we can not encrypt the file with the pubkey of the recipient.

We can not simply store the decryption key on the ethereum blockchain, this key would be visible to anyone and thus people would be able to access the encrypted file on IPFS without eg. payment.

One solution is to save the decryption keys that belong to their assets on a seperate centralized datastore, making a single point of failure for our dApp yet again possible.

So Iā€™m wondering if there are any solutions to solve this problem like safely storing the decryption keys on-chain.

Many thanks.

2

So, encrypting data to multiple parties and ensuring a fair exchange for data are really separate problems.

The former can be accomplished by encrypting files with symmetric keys and then giving out the symmetric keys as necessary (theyā€™re effectively bearer tokens).

There are several solutions to the payment problem but they all tend to revolve around proving that the data is actually the requested data and they usually require both the buyer and the seller to be online. Usually, the seller ends up chunking the file into pieces, encrypting each chunk with a separate key, and ā€œcommittingā€ to the keys. When a buyer tries to buy the data, the buyer can ask for some sample data to be decrypted. If the buyer is happy, they pay to have the entire key posted to the blockchain. For privacy, one would probably want to encrypt the file with two keys (one sent to the buyer out of band before beginning the transaction).

One interesting addition to this would be some form of reusable contract. Ideally, one would be able to let the blockchain pick the sample data to reveal once. After that initial reveal, youā€™d want to be able to sell keys to multiple parties using the same contract/sample data. However, I canā€™t think of a solution off the top of my head.

3

The fair exchange problem could partially be solved by economic game theory and is a different issue iā€™m not concerned about right now.

Itā€™s the first problem that is a thorn in my eye.

Even when using symmetric keys, where do I store them?
I canā€™t simply store it unencrypted on the blockchain/Smart contract.

Maybe I should have clarified that the distribution happens through a smart contract which a buyer can interact with. The seller is really there for nothing but receiving the funds.

Hereā€™s a similar project : www.opus-foundation.org

Page 14
3.  TECHNOLOGY
Playing songs from IPFS using keys in the Opus smart contract:
playSong: (licenseAddress)=>{
App.loadPlayingToPage(licenseAddress);
var
Opus;
App.getSongFromAddress(licenseAddress).then(
function
(instance) {
Opus = instance;
return
Opus.requestKeyandHash.call({from: account});
}).then((res) => {
var
_key = res[0];
var
_hash = res[1];
var
_url = App.gatewayUrlfromHash(_hash);
var
_player = document.getElementById("audioplayer");
_player.src = _url;
App.playbackwithKey(licenceAddress, _key);
}).
catch
((e) => {
console.log(e);
})
},
4

Most systems that rely on game theory also rely on reputation and tend to be vulnerable to syble attacks so you have to be careful here. However, itā€™s entirely possible to build an exchange system that doesnā€™t rely on game theory.

So, thatā€™s a research question. I believe itā€™s doable but youā€™d probably need to work with a cryptographer.