multiparty / psi-pilot-masstech Goto Github PK

Party A can receive requests for its masked table (generated in #3), and should respond with this data. In this pilot we will use a shared secret/password between Party A and B, which should be part of the request. If the password does not match, Party A should respond with a 403 message.

We want to protect against parties learning when a particular record was added to the database. In the p2p model, forward secrecy is obtained by changing the key for Party A whenever a new record is added to the table. A now raises all entries to this new key, and shuffles the table. Party B then has to download this new table to perform a query.

In the outsourced model, we can limit the amount of data being sent between Party A and the compute parties when new records are added. Instead of re-sending shares of every entry in the table, only shares of new entries have to be sent. The compute parties now pick a new key, and perform the protocol of #9 with just those new shares. In parallel, raise the old data to the multiplicative inverse of the old key (to remove it), then raise it again to the new key. Send this to the next compute party, who performs the same operation with its new key. Complete this for every compute party. The final compute party sends the entries back to the others, and they all shuffle this table. This refreshes the old data with a new set of keys.

Similar to what Party A does in #8, Party B who wants to perform a private set membership test will raise its set of entries to a key (which it keeps track of), then splits them into shares and sends them to all compute parties. Keep the connection to this request open, since all compute parties will respond with the same result. When scaling this up, we might want to think about a better way of doing this (asynchronously).
The compute parties perform the same exercise as in #9. They mask with their key and send it along to all other compute parties. Once the entry has been raised to all keys and added together, send the result back as a response to Party B. If Party B already downloaded the table from #10, it can perform a scalarMult with its inverse key and then see if there's a match.
Connection details (IP and password) for compute parties are part of a config file.

We will not be using actual banking data in this project. For now, it would suffice to generate a CSV file of fake social security numbers. The generator should have a parameter to define how many records to be generated. This file should be part of .gitignore.

Similar to #5, but in the outsourced model. Party B should be able to query any compute party for its masked table (or the table is published to a centralized source).

As Party B I have a list of entries I want to match up with Party A's database. First mask all entries with an ephemeral key (needs to be remembered until you have Party A's table from #5), then send them to Party A. We assume the IP of Party A is known upfront. The response will be your entries that are now also masked with Party A's key. As usual, send the password along to this request.

After receiving a list of shares from Party A in #8, each compute party will mask (scalarMult with random key) these shares with a key. This key should only be used for Party A, and only for this set of shares. If Party B sends their shares, a different key should be used (and kept track of). If Party A sends a new set a shares, a new key should also be used.
Once the shares have been masked with your key, send them along to the next compute party. At the same time, accept an incoming set of masked shares from a different compute party and mask them again with your key. Make sure these shares belong to the same Party A. Do this for every single compute party. I.e. if there are 3 compute parties, A, B, and C, A will send shares to B and C twice, and receive shares from B and C twice. In the end all compute parties will have the same set of shares raised to keys ABC. Adding these shares together produces a table of entries masked with keys A, B, and C.
Store a copy of the masked entries. Connection details of other compute parties (IP and password) will be part of a config file.

Party A masks their input and stores the results. This will be done using the OPRF library. Look at the steps of maskInput, but we need to be able to provide our own key since all records will be masked with one key. Retrieve this key from either a file, or an environment value. Store the results in a file, which is part of .gitignore.

Party A should be able to accept incoming queries. A query will be in the form of a list of identifiers. All entries in this list have to be raised (scalarMult) to the key Party A also used for its table. The result has to be sent back to Party B.
In this pilot we will use a shared secret/password between Party A and B, which should be part of the request. If the password does not match, Party A should respond with a 403 message.

In our outsourced model, the data of Party A isn't masked and stored by A. Rather, it is split into n additive secret shares (sum of all shares equals masked point), with each share being sent to a compute party. For this we have to modify the OPRF library to add addition and subtraction calls to Libsodium's Ristretto implementation. The documentation can be found here.
Perform this operation for all entries derived from #1. Shares for all entries will be sent in one payload, assuming no chunking is needed. Connection details (IP and password) for all compute parties will be part of a config file.

Create a method that ingests a CSV file, and outputs a list of rows. The function should have a parameter that allows skipping of the header.

After #5 and #6, we have all the information we need to determine a match between Party A and Party B's records. Party B unmasks the result of #6, using the same key that initially masked the entries (see unmaskPoint in OPRF). This gives you your entry masked with Party A's key, which can be compared with the entries in A's table.