Ruby Protocol

• Proposer: Ruby Protocol
• Payment Address: 0x5aBBe7b65c572b9f5Cc7655Ba4a1Acad0e892720

Project Overview 📄

Overview

Introduction

This project will design and implement a fine-grained personal data monetization framework, which would serve as a second-layer/middleware protocol interacting with the substrate module. The framework will enable a data owner to enforce a fine-grained access control policy over his/her encrypted private data using functional encryption, and share predefined computation results over the private data with a data purchaser in exchange for economic compensation. The access control policy will be built into the substrate module, and the data monetization transaction will also execute via substrate module, which is why this solution is defined as a second-layer/middleware protocol.

Project Details

Project Architecture

Functional encryption was originally proposed as a fine-grained access control mechanism over encrypted data [GPSW06]. A data owner encrypts a message x to generate ciphertext, which could be stored in an untrusted cloud server. The project might pay for the hosting expenses initially to jump-start the project, but we will gradually transfer the cost to the data owner since it would make sense for them to pay for their data monetization business. A data purchaser might wish to compute a function f over the encrypted message. With the consent of the data owner, a data purchaser would receive a secret key sk_f from a key distributor. The data purchaser can then use the private key sk_f to decrypt the ciphertext to compute f(x). Note the data purchaser cannot retrieve any other information on the underlying message except the final decryption result f(x). To prevent the data owner from accepting payment and then immediately removing their data from the cloud before the data purchaser receives the data, the data purchaser needs to retrieve the encrypted data before paying the owner.

Here is a more concrete example for functional encryption: the message here could be the user’s genomic data, and f could be a statistical analysis algorithm. The data purchaser could be a research institute intended to perform private statistical analysis over one’s genomic data. The secret key might be generated by the hospital that collects the users' genomic data or the data owner themselves. At the end of this transaction, the data owner will receive economic compensation for one's contribution to the computation result while the data purchaser will receive the statistical analysis results. In other cases, the data could also be one’s social network data and the function could be an analytics algorithm for online advertisement. We envision the monetary exchange between the data owner and purchaser will be executed as a substrate module.

This project will implement a second-layer/middleware protocol running on Polkadot that enables individuals to monetize their private data in a fine-grained fashion. The delivery will include:

• A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption.
• A substrate module that implements the encryption of the cryptographic keys of the functional encryption scheme and the associated zero-knowledge proof for its legitimacy.
• A micropayment scheme running on the Polkadot blockchain can allow individual users to monetize their data.

Here are the basic principles behind the overall architecture design of the fine-grained personal data monetization framework. We aim to keep the workload of the data owner minimum. This implies the online time of the data owner should be kept to a minimum. The optimal case would be the data owner is left alone after he generates and uploads the ciphertext. Ideally, the encryption workload of the data owner should also be kept as minimal as possible. The following scheme can be viewed as a generalization of the knowledge monetization scheme proposed in [TZLHJS2017].

The general idea is shown in Fig. 1. A functional encryption scheme usually consists of four algorithms:FE.Setup(1^\lambda), FE.KeyGen(msk, f), FE.Enc(mpk, x) and FE.Decrypt(Key_f, FE.Enc(mpk, x)). At the beginning of the system, the key distributors run the FE.Setup(1^\lambda) algorithm to generate the master public key mpk and master secret key msk. Here \lambda denotes the security parameter. When a data owner wishes to sell his data, he encrypts his data x by running the FE.Enc(mpk, x) algorithm and uploads the output ciphertext Enc(x) to the untrusted cloud. He then specifies the pricing model with respect to different functions f’s in a substrate module SC, and posts it to the Polkadot blockchain. When a data purchaser intends to calculate f(x), he will first generate a commitment of an appropriate amount of coin based on the pricing of the function f and his own public key PK_P as a transaction to call the module SC.

The substrate module should return a receipt to the data purchaser, who will in turn present it to the key distributor. The key distributor, after verifying the receipt and the respective coin commitment, runs the FE.KeyGen(msk, f) algorithm to generate the function key Key_f for the data purchaser.

Simultaneously, the distributor will send SC the encryption of Key_f under the data purchaser’s public key PK_P, denoted as Enc_(PK_P)(Key_f) and an associated zero-knowledge proof proving Key_f is indeed a well-formed function key corresponding to f. SC with the inputs from both the key distributor and data purchaser is then verified by the Polkadot blockchain. Once the verification for both sides passes, meaning the amount of the committed coin is sufficient to pay for the decryption result f(x) and the gas fee, and the associated zero-knowledge proof is correct, the payment will be released to the data owner. The data purchaser can then download the ciphertext and decrypt f(x) by running the FE.Decrypt(Key_f, FE.Enc(mpk, x)) algorithm.

Note once the verification of SC is passed, SC will execute and payment is released to the data owner instantaneously. To ensure fairness towards the data purchaser, the data owner should provide verifiable evidence to prove his data source. FE.Enc(x) is accompanied by a certified signature Sig_D(FE.Enc(x)) to prove the data is coming from the right source and thus the data quality can be guaranteed. Here D denotes the private key of the data source. The data source could charge an extra service fee from the data owner when the data owner first meets the data source (goes to the hospital and does the test in the genomic computation example) and decides to join the monetization program. We note even though the data source (the hospital in the genomic computation example) is the one that produces the data, it doesn't necessarily mean that it owns the patients' data. For instance, according to this report, some states in the US explicitly give patients ownership of their health data. In other words, only the patient can dictate how the data should be monetized. Although it might be tempting to let the data source be representative of the data owners and handle the monetization of their private data, it would both go against both the law and the ethos of the project, which is to put the control of one's data back in the hands of the owner.

The design of the underlying functional encryption scheme, where the private key should correspond to the function chosen by the data purchaser. Since the encryption of the private key should be presented as evidence (as shown in Fig. 1) and verified on the blockchain, the private key should be of minimum size, preferably constant size. To keep the workload of both the data owner and key distributor minimal, the encryption time and key generation time should be as short as possible.

There exist several functional encryption schemes with constant key size such as the one presented in [SC2017,CRH2015, RDGBP2019,B2017,MSHBM2019]. General predicate encryption allows the data owner to encrypt the raw data items tagged with various attributes, and a data purchaser to query different parts of the data repository using a function key corresponding to a predicate. Inner product predicate encryption [CGW2015] is a special kind of predicate encryption, where the data purchaser could retrieve the data records if the inner product of their attribute vector y and the predicate vector x specified by the data purchaser is equal to 0. For instance, the data purchaser could potentially ask for the data records corresponding to a conjunctive predicate such as “Age”AND“gender”AND“Income” from a personal data repository. One of the most efficient inner product encryption schemes [CGW2015] has a private key consisting of four elliptic curve group elements, and its key generation is dominated by four modular exponentiations.

While the predicate encryption allows the data purchaser to retrieve different parts of a database based on a predefined predicate, a more general functional encryption allows the data purchaser to calculate an arbitrary function over the input x. This project will focus on a slightly narrow set of functional encryption schemes: inner product encryption and quadratic polynomial function encryption [MSHBM2019]. In an inner product encryption scheme, for encryption of a vector x, the data purchaser with a private key corresponding to another vector y will be able to compute the inner product between x and y. On the other hand, in a quadratic polynomial functional encryption scheme, the data owner will encrypt two vectors v_1 \in \mathbb\{Z}_n and v_2 \in \mathbb\{Z}_n, a data purchaser with a secret key corresponding to a matrix H \in \mathbb\{Z}^\{n*n} is allowed to decrypt the quadratic product of x_1, x_2, and H, i.e., x_1^T\cdot H \cdot x_2. Both inner product encryption and quadratic polynomial functional encryption can support sophisticated privacy-preserving machine learning tasks, such as classification [LCFS2017,SGP2018] and neural networks [RDGBP2019].

The benchmark results for various inner product encryption and quadratic polynomial function encryption schemes can be found in [MSHBM2019]. The private key of inner product encryption consists of one elliptic curve group element, which is of 256 bits under 128-bit level security. The key generation for a vector of 100 elements takes 0.4149s, and the encryption time for the data owner is around 0.2103s for a vector of the same size. The private key of quadratic polynomial functional encryption also only consists of one elliptic curve group element. The average key generation and encryption time for each coordinate of the message vector is 0.001s and 0.025s.

In terms of the accompanied zero-knowledge proof scheme, the statement of the zero-knowledge proof scheme should be to convince the verifier that the encrypted content is a well-formed function key with regards to a predefined function in the module. Since the verification of the zero-knowledge proof should be verified by the blockchain, we need to make sure the verification is efficient and the proof size is as small as possible. The candidate zero-knowledge proof scheme for this is zk-snark implementation such as ZeroPool, which is an implementation of Groth16 scheme. The proof generation time is comparatively short for the previously mentioned encryption schemes since the respective statement (determined by the key generation algorithm and the public key encryption) is quite simple.

According to the pricing model of data monetization, a report presented by OECD [RRS2013] classifies the existing practical pricing models of personal data into two major categories: based on market valuation and individual valuation. The approach based on individual valuation suffers from the defect that the individual valuation of the private data is extremely context-dependent and cannot be measured with precision and certainty. The market-valuation-based approach can be further divided into the following sub-categories: market cap per data record, market prices for data, cost of a data breach, and data prices in illegal markets.

The approach based on market prices for data is particularly interesting given that data brokers usually publicly broadcast their asking prices for various personal data records. Our platform can easily aggregate and compare across various data brokers to use it as the proxy pricing model of the individual personal data record. One could further refine these data prices based on the queried function and adopt a fine-grained pricing approach used by DirectMail [MDJM2019]. They give an example where the base price per record is equal to $0.045 and the predicate-based price per record is equal to$0.0035 + $0 +$0.004 = $0.0075 (for example, calculated from the aforementioned conjunctive predicate). Thus, the total price per record for predicate encryption would be equal to$0.045 + $0.0075 =$0.0525. For the inner product encryption or quadratic polynomial function encryption, the price of the decryption result will exclude the base price of the record.

This will be one of the pricing strategies we adopt in phase 1 and phase 2 of our project. In the later development of our project, we will explore more algorithmic pricing approaches such as Automated Market Maker’s (AMMs), where the platform estimates how much the data purchaser is willing to pay for data of different qualities and determines the concrete data pricing model.

Team Interest

The Ruby Protocol team consists of seasoned engineers, cryptographers, data scientists and cryptocurrency early adopters. Our team has a very deep understanding of data monetization and zero-knowledge algorithms. The expertise in cryptography has allowed us to deliver impressive results The background of the team consists of both engineering and academic backgrounds. We believe that Decentralized Data (DeData) will be the next massive adoption market after Decentralized Finance (DeFi).

Substrate/Polkadot Integration

We will leverage the existing cryptographic library in the Polkadot ecosystem, such as ZeroPool to build the underlying cryptographic library that implements the zero-knowledge proof for the legitimacy of the encrypted functional key. We will also integrate the existing inner product functional encryption and quadratic polynomial functional encryption with the Polkadot ecosystem. Furthermore, we will also build a substrate pallet that integrates the verification logic of the associated zero-knowledge proof and provide the necessary UI for the users to interact with all these algorithms and invoke the aforementioned cryptographic modules and the micropayment scheme.

Open API and SDK

The ultimate goal of Ruby Protocol is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot, including:

• A cryptographic library that implements the inner product functional encryption and quadratic polynomial functional encryption. A substrate module that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.
• The client can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms.

Ecosystem Fits

The existing internet economic model relies almost exclusively on the monetization of personal data. The recent scandals on the internet companies mishandling individual data such as Facebook’s Cambridge Analytica scandal have prompted many individuals to awaken to the fact that in the current internet economy they are the product and they need to regain control over their data. In fact, I would argue that the recently published privacy regulation such as GDPR or CCPA is the response to this urge.

Polkadot could act as an indispensable role to remove the middleman of the internet economy. A second-layer fine-grained personal data monetization framework based on Polkadot would potentially move Polkadot beyond a decentralized financial platform and enable Polkadot to play a central role in the next-generation data economy. It would also enable Polkadot to gain a moral high ground by freeing billions of web users from the control of monopoly middleman companies.

The following is the reason why a cross-chain platform such as Polkadot is a perfect platform to implement a decentralized and transparent data monetization mechanism: The monetary return of one single data monetization transaction tends to be small. The economic benefit to the data owner can only be noticeable when this type of micropayment happens frequently. However, the mental cost incurred by having to deal with frequent micropayment might render it undesirable. Substrate module as publicly verifiable, self-enforcing code could help amortize the mental cost.

The substrate module will specify the types of computation the data purchaser is allowed to perform over the ciphertext. Since the same computation result could be of different values to different data purchasers, automatic payment based on substrate module could be used to enforce sophisticated pricing models to guarantee the maximum economic return for the data owner.

A publicly verifiable substrate module would not only help with the transparent enforcement of various privacy regulations such as General data protection regulation (GDPR) or California consumer privacy act (CCPA) but also ensure the fairness of data monetization transactions without the involvement of any middleman [TZLHJS17]. This is in stark contrast with the opaque business model of the existing internet economy where giant internet companies absorb all the economic benefits of personal data monetization. Our framework will let individuals regain control of their private data.

We all know the slogan “Data is the new oil”. According to alliedmarketresearch.com, the global data monetization market size was valued at $44869 in 2016, and is projected to reach at$370969 million by 2023, growing at a CAGR of 35.4% from 2017 to 2023. Even by capturing a small piece of this market, it would bring enormous economic benefits to the Polkadot ecosystem.

A second-layer fine-grained data monetization framework will also greatly expand the Polkadot community through attracting not only privacy-conscious users but also business partners hunger for high-quality data such as research institutes, hospitals, traditional financial institutes, etc.

There are three relevant projects: the first one is perhaps the Enigma project, a privacy protocol that enables the creation of decentralized applications that guarantee privacy. The protocol Enigma bases on is secure multi-party computation (MPC). The second one, Insights Network is a data exchange based on combining blockchain technology, substrate module, and MPC. It is based on the EOS blockchain and a custom MPC system. The third one, NuCypher is a cryptographic infrastructure for privacy-preserving applications. Its main technology is threshold proxy re-encryption and fully homomorphic encryption. None of these second-layer protocols are built for the Polkadot ecosystem.

There are several different ways of implementing an MPC protocol: threshold homomorphic encryption, garbled circuit, and secret sharing. The general idea of MPC is to outsource private data (either in the form of secret shares or homomorphic encryption) to a few separate computing parties so that they can perform confidential computation over the encrypted data. Directly applying MPC to fine-grained personal data monetization is problematic in the sense that once the data is outsourced, the data owner does not exert any control over what type of computation can be performed by the computing party. In other words, individual privacy is now at the mercy of these computing parties, which is against the human-centric ethos of fine-grained personal data monetization, where the access control policy should be defined by the data owner and enforced by the algorithm. On the other hand, functional encryption was specifically proposed and tailored for enforcing fine-grained access control over encrypted data. By allowing the data owner to define the access control policy, the owner has full control over what type of access the data purchaser can have over the encrypted personal data. The only decryption result the data purchaser will be able to retrieve is the predefined function evaluation.

Team 👥

Team Members

• David Spade - Full-stack Software Engineer
• Kevin Hsu - Data Scientist
• Dylan Dewdney - Marketing Advisor
• Beni Issembert - Strategy Advisor

Team Website

• http://rubyprotocol.com/

Legal Structure

• Ruby Technology Ltd. is a company registered in the Cayman Islands.

Team Experience

David Spade
David Spade graduated from the University of Nottingham. He is a full-stack developer with 8 years of experience in software development. David also has deep knowledge in zero-knowledge algorithms and he is an expert in data science.

Kevin Hsu
Kevin Hsu graduated from MSc in Computational Statistics and Machine Learning from UCL and was supervised by David Silver, the senior engineer of AlphaGO. He served as a data scientist in Credit Suisse, senior machine learning Engineer in WeCash. Prescient and consistent track-record in investment and has invested in over 160 blockchain projects around the world.

Beni Issembert
Beni Issembert is a former Beam Privacy CMO, and currently works as Concordium CMO (a Proof-of-stake for businesses backed by IKEA, Volvo,and Geely). He has a Ph.D. in Philosophy of Sciences from John Hopkins and has been working in the digital world as an entrepreneur since 2005. Beni is a published author and respected thought leader in Blockchain, specifically within areas of privacy and identity.

Dylan Dewdney
Dylan Dewdney is a longtime crypto enthusiast (2011). In 2017 he co-founded Harbour DAO, which became an open-standard set of tools for building governance structures and voting mechanisms on ERC-20. Later, as Chief Evangelist of Beam and Head of Growth for AdEx, he was a key part of their GTM and general growth strategies. Dylan is a respected peer among many different projects and areas of business.Dylan is also the project lead and CEO of DeData project Kylin Network.

Team Code Repos

• https://github.com/Ruby-Protocol

Team Linkedin Profiles

• www.linkedin.com/in/dylan-dewdney

• www.linkedin.com/in/beniissembert

• www.linkedin.com/in/yingkaixu

Development Roadmap 🔩

Overview

• Total Estimated Duration: 2 months

• Full-time equivalent (FTE): 3 FTE

• Total Costs: 30,000 DAI

Milestone 1 — Implement Cryptographic Modules

• Estimated Duration: 5 months

• FTE: 1

• Costs: 10K DAI

The main deliverable of this milestone includes:

• A cryptographic library written in Rust that implements the inner product functional encryption and quadratic polynomial functional encryption.

• A substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.

Number	Deliverable	Specification
0a.	License	Apache License 2.0
0b.	Documentation	We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
0c.	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.	Article/Tutorial	We will publish a medium article that explains the functionality of the proposed cryptographic library and substrate pallet delivered in this milestone.
1.	Cryptographic modules	We will implement the cryptographic modules including inner product functional encryption and quadratic polynomial functional encryption [MSHBM2019] and the associated zero-knowledge proof [ZeroPool]. The cryptographic modules will be written in Rust and modified from the rust version of CiFEr library. We will build privacy-preserving classification and neural networks based on these modules. We will also implement a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.
2.	Benchmark	Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the gas cost and throughput of the proposed module.
3.	Docker	We will provide a dockerfile to demonstrate the usage of our modules.

Milestone 2 —— Client Implementation and Integration

• Estimated Duration: 1 month
• FTE: 2
• Costs: 20K DAI

The main deliverable of the milestone is the client that can trigger the aforementioned cryptographic modules and the micropayment scheme and the necessary UI to enable the users to interact with all these algorithms.

Number	Deliverable	Specification
0a.	License	Apache License 2.0
0b.	Documentation	We will provide both inline documentation of the code and a basic tutorial that explains how a user can (for example) spin up one of our Substrate nodes. Once the node is up, it will be possible to send test transactions that will show how the new functionality works.
0c.	Testing Guide	Core functions will be fully covered by unit tests to ensure functionality and robustness. In the guide, we will describe how to run these tests.
0d.	Article/Tutorial	We will publish a medium article that explains the functionality of the proposed client and UI delivered in this milestone.
1.	Client modules	We will implement the client to support the key distribution and decryption of the functional encryption scheme [MSHBM2019]. The client will also generate the transaction that can trigger the aforementioned cryptographic modules and the micropayment scheme [MDJM2019], such as the encrypted functional key and zero-knowledge proof. We will provide a basic UI to take inputs from the users for all these algorithms and receive the outputs. More specifically, the UI will enable the data owner to input the raw data to generate the signed ciphertext and upload it to the cloud server. The UI will also allow the data purchaser to retrieve the functional key from the key authority and the ciphertext from the cloud and then perform the decryption. The UI will also register a qualified data source and allow a data owner to join the data monetization program when he/she meets the data source and the data owners to request a signature from a registered source, which will then be verified on-chain. Finally, it will also allow these entities to interact with the substrate module with the inputs and outputs defined in our architecture.
2.	Benchmark	Perform unit tests on the individual algorithms to ensure their safety. Benchmark on the latency and usability of the proposed client functionalities.
3.	Docker	We will provide a dockerfile to demonstrate the usage of our modules.

Community Engagement

• Bounty Program for General Community: We will reward users who contribute positively to community building and content creation through an Ambassador Program. The community management team will be available 24/7 to answer questions.

• Incentive Program for Data Monetization: After the main functions are completed, we will provide incentives for users to monetize their data on our platform. This is an encouragement for users to provide the data and purchase the data.

• Parachain Loan Offering Campaign: We may hold a Parachain Loan Offering and reward users for helping our auction with Ruby Protocol tokens.

• Affiliated Program of Cryptographic Infrastructure: It is proven effective for user growth and can be integrated into Ruby’s cryptographic infrastructure.

Future Plans

We will hire at least 8-10 more devs in the next three months. Meanwhile, we will apply for the Substrate Builder's Program. After that, Ruby Protocol wants to become a parachain for the Polkadot network. We have some preparations for auction and we may design a community-wide LPO.

In phase 1, we will complete the implementation of cryptographic modules as a substrate pallet that integrates the verification logic of the associated zero-knowledge proof for the legitimacy of the encrypted functional key.

In phase 2, our goal is to deliver the micropayment scheme and enable the users to interact with all these algorithms in a working product.

Finally, our goal is to provide an essential open API and SDK from a high-level perspective with the above tools, fully powering the data monetization framework on Polkadot.

Additional Information ➕

Reference

[GPSW06] Goyal, V., Pandey, O., Sahai, A., & Waters, B. (2006, October). Attribute-based encryption for fine-grained access control of encrypted data. In Proceedings of the 13th ACM conference on Computer and communications security (pp. 89-98).

[GGGJKLZ14] Goldwasser, S., Gordon, S. D., Goyal, V., Jain, A., Katz, J., Liu, F. H., ... & Zhou, H. S. (2014, May). Multi-input functional encryption. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (pp. 578-602). Springer, Berlin, Heidelberg.

[GKPVZ13] Goldwasser, S., Kalai, Y., Popa, R. A., Vaikuntanathan, V., & Zeldovich, N. (2013, June). Reusable garbled circuits and succinct functional encryption. In Proceedings of the forty-fifth annual ACM symposium on Theory of computing (pp. 555-564).

[ALS2016] Agrawal, S., Libert, B., Stehle, D.: Fully secure functional encryption for inner products, from standard assumptions. In: Annual International Cryptology Conference. pp. 333-362. Springer (2016).

[B2017] Bourse, F. (2017). Functional encryption for inner-product evaluations (Doctoral dissertation).

[B2018] Vitalik Buterin, https://ethresear.ch/t/on-chain-scaling-to-potentially-500-tx-sec-through-mass-tx-validation/3477, 2018.

[BCTV2013] Eli Ben-Sasson, Alessandro Chiesa, Eran Tromer, and Madars Virza. Succinct non-interactive zero knowledge for a von Neumann architecture. In Proceedings of the 23rd USENIX Security Symposium, Security '14. Available at http://eprint.iacr.org/2013/879.

[BMEB2016] Bataineh, A. S., Mizouni, R., El Barachi, M., & Bentahar, J. (2016, June). Monetizing Personal Data: A Two-Sided Market Approach. In ANT/SEIT (pp. 472-479).

[CGW2015] Chen, J., Gay, R., & Wee, H. (2015, April). Improved dual system ABE in prime-order groups via predicate encodings. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (pp. 595-624). Springer, Berlin, Heidelberg.

[FVBG17] Fisch, B., Vinayagamurthy, D., Boneh, D., & Gorbunov, S. (2017, October). Iron: functional encryption using Intel SGX. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (pp. 765-782).

[LCFS2017] Ligier, D., Carpov, S., Fontaine, C., & Sirdey, R. (2017, February). Privacy Preserving Data Classification using Inner-product Functional Encryption. In ICISSP (pp. 423-430).

[MDJM2019] Mehta, S., Dawande, M., Janakiraman, G., & Mookerjee, V. (2019). How to sell a dataset? pricing policies for data monetization. Pricing Policies for Data Monetization (August 1, 2019).

[MSHBM2019] Marc, T., Stopar, M., Hartman, J., Bizjak, M., & Modic, J. (2019, September). Privacy-Enhanced Machine Learning with Functional Encryption. In European Symposium on Research in Computer Security (pp. 3-21). Springer, Cham.

[PHGR2013] Parno, B., Howell, J., Gentry, C., & Raykova, M. (2013, May). Pinocchio: Nearly practical verifiable computation. In 2013 IEEE Symposium on Security and Privacy (pp. 238-252). IEEE.

[RDGBP2019] Ryffel, T., Dufour-Sans, E., Gay, R., Bach, F., & Pointcheval, D. (2019). Partially encrypted machine learning using functional encryption. arXiv preprint arXiv:1905.10214.

[RRS2013] Reimsbach-Kounatze, C., Reynolds, T., & Stryszowski, P. (2013). Exploring the economics of personal data-a survey of methodologies for measuring monetary value.

[SC2017] Agrawal, Shashank, and Melissa Chase. "Simplifying design and analysis of complex predicate encryption schemes." Annual International Conference on the Theory and Applications of Cryptographic Techniques. Springer, Cham, 2017. [SGP2018] Sans, E.D., Gay, R., Pointcheval, D.: Reading in the dark: Classifying encrypted digits with functional encryption. IACR Cryptology ePrint Archive 2018, 206, (2018).

[TZLHJS2017] Florian Tramer, Fan Zhang, Huang Lin, Jean-Pierre Hubaux, Ari Juels, and Elaine Shi. ”Sealed-glass proofs: Using transparent enclaves to prove and sell knowledge.” In Security and Privacy (EuroS&P), 2017 IEEE European Symposium on, pp. 19-34. IEEE, 2017.