Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
SECURE COMPUTATION
Document Type and Number:
WIPO Patent Application WO/2017/001872
Kind Code:
A1
Abstract:
A secure computation method for executing first instructions issued by a first party and second instructions issued by a second party, the method comprising the steps of generating by the first party a garbled Boolean circuit (C'). Sending data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GC1) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC2) has input wires configured to receive the second instructions and associated with a second key (k[1]). Sending the first key (k[0]) and the second key (k[1]) from the first party to the second party using an oblivious transfer. The second party obtaining an output from the first garbled Boolean circuit (C') using the first key (k[0]). The second party providing the second instructions to the input wires of the second copy of the garbled Boolean circuit (C') and obtaining an output from the second copy of the garbled Boolean circuit (GC2) using 1 the second key (k[1]). The second party providing the first party with the output of the second copy of the garbled Boolean circuit (GC2). Executing the first and second instructions if the first and second parties determine from the outputs of the first and second copies of the garbled Boolean circuits (GC2,GC2) that the first and second instructions are compatible. A trading system architecture comprising a communications interface for providing communications with a first party and a second party. At least one processor. Memory storing executable instructions configured to, when executed by the at least one processor, cause the trading system architecture to receive first trading instructions from the first party receive first trading instructions from the second party exchange data over the communications interface between the first party and the second party using an oblivious transfer mechanism based on the first and second trading instructions the first and second parties determine that the first trading instructions are compatible the second trading instructions without revealing first trading instructions to the second party and without revealing the second trading instructions to the first party using the exchanged data. If the first trading instructions are determined to be compatible with the second trading instructions then executing a trade between the first party and the second party corresponding to the first and second trading instructions.

Inventors:
FOTHERINGHAME, David (5 The North ColonnadeCanary Whar, London Greater London E14 4BB, E14 4BB, GB)
LINDELL, Yehuda (Bar Ilan University, Ramat Gan, 52900, IL)
PINKAS, Benny (Bar Ilan University, Ramat Gan, 52900, IL)
Application Number:
GB2016/052014
Publication Date:
January 05, 2017
Filing Date:
July 01, 2016
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
BARCLAYS BANK PLC (29th Floor, One Churchill PlaceCanary Wharf, Greater London E14 5HP, E14 5HP, GB)
International Classes:
G06Q10/00
Domestic Patent References:
2014-04-03
Foreign References:
US20120233460A12012-09-13
Other References:
ANDREW C YAO ET AL: "Protocols for secure computations", FOUNDATIONS OF COMPUTER SCIENCE, 1982. SFCS '08. 23RD ANNUAL SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, USA, 3 November 1982 (1982-11-03), pages 160 - 164, XP031288185
Attorney, Agent or Firm:
BOULT WADE TENNANT (Verulam Gardens, 70 Gray's Inn Road, London WC1X 8BT, WC1X 8BT, GB)
Download PDF:
Claims:
CLAIMS:

1 . A secure computation method for executing first instructions issued by a first party and second instructions issued by a second party, the method comprising the steps of: generating by the first party a garbled Boolean circuit (C);

sending data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC2) has input wires configured to receive the second instructions and associated with a second key (k[1 ]);

sending the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

the second party obtaining an output from the first garbled Boolean circuit (C) using the first key (k[0]);

the second party providing the second instructions to the input wires of the second copy of the garbled Boolean circuit (C) and obtaining an output from the second copy of the garbled Boolean circuit (GC2) using the second key (k[1 ]);

the second party providing the first party with the output of the second copy of the garbled Boolean circuit (GC2); and

executing the first and second instructions if the first and second parties determine from the outputs of the first and second copies of the garbled Boolean circuits (GC2,GC2) that the first and second instructions are compatible.

2. The method of claim 1 , wherein the second instructions are encoded from a first input Y\o a second input Y' according to:

Y'=L \ R

Where ^is / bits long, Y' is of length 2/ bits, L and R are both / bits long, L is chosen uniformly at random, and R=L®Y. 3. The method of claim 1 or claim 2, wherein the oblivious transfer has a deterrent factor of ¼.

4. The method according to any previous claim, wherein the first instructions and the second instructions include an indication (side! , side2) of the trades being an instruction to buy an instrument or to a sell an instrument.

5. The method of claim 4, wherein the first and second instructions define a size of the trade.

6. The method of claim 4, wherein the first and second instruction include a trading instrument (instrument! , instrument2).

7. The method according to any of claims 4 to 6, wherein determining from the outputs further comprises determining that the first instructions are a trade instructions to buy the instrument and the second instructions are trade instructions to sell the instrument.

8. The method according to any of claims 4 to 6, wherein the Boolean circuit (C) is configured to:

compute instrumenti = instrument2, and sidei≠ side2. 9. The method of claim 8, wherein the first and second instructions further include a trading limit.

10. A system for executing first instructions issued by a first party and second instructions issued by a second party, the system comprising:

at least one processor; and

memory storing executable instructions configured to, when executed by the at least one processor, cause the apparatus to:

generate for the first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC2) has input wires configured to receive the second instructions and associated with a second key (k[1 ]);

send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled Boolean circuit (C); obtain an output from the second copy of the garbled Boolean circuit (GC2) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC2);

determine from the outputs of the first and second copies of the garbled

Boolean circuits (GC2,GC2) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties.

1 1 . The apparatus of claim 10, wherein the instructions are executed as part of an application programming interface, API.

12. A trading system architecture comprising:

a communications interface for providing communications with a first party and a second party; and

at least one processor;

memory storing executable instructions configured to, when executed by the at least one processor, cause the trading system architecture to:

receive first trading instructions from the first party;

receive first trading instructions from the second party;

exchange data over the communications interface between the first party and the second party using an oblivious transfer mechanism based on the first and second trading instructions;

the first and second parties determine that the first trading instructions are compatible the second trading instructions without revealing first trading instructions to the second party and without revealing the second trading instructions to the first party using the exchanged data; and

if the first trading instructions are determined to be compatible with the second trading instructions then executing a trade between the first party and the second party corresponding to the first and second trading instructions.

13. The trading system of claim 12 further comprising an application programming interface configured to exchange the data between the first and second parties.

14. The trading system of claim 12 or claim 13, wherein the executable instructions further cause the trading system architecture to:

generate for the first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC2) has input wires configured to receive the second instructions and associated with a second key (k[1 ]);

send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled Boolean circuit (C);

obtain an output from the second copy of the garbled Boolean circuit (GC2) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC2);

determine from the outputs of the first and second copies of the garbled Boolean circuits (GC2,GC2) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties.

15. The trading system architecture according to any of claims 12 to 14, wherein the first trading instructions and the second trading instructions include an indication of a buy instruction or a sell instruction and a trade size.

16. The trading system of claim 15, wherein the first trading instructions and the second trading instructions further include any one or more of an instrument identifier, a price limit, a toxicity offset and a mid-price mismatch tolerance.

17. One or more non-transitory computer-readable media storing instructions configured to, when executed, cause at least one computing device to:

generate for a first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit (C) to a second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining first instructions issued by the first party and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC2) has input wires configured to receive second instructions issued by the second party and associated with a second key (k[1 ]);

send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled Boolean circuit (C);

obtain an output from the second copy of the garbled Boolean circuit (GC2) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC2);

determine from the outputs of the first and second copies of the garbled

Boolean circuits (GC2,GC2) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties.

18. The one or more non-transitory computer-readable media of claim 17, wherein the garbled Boolean circuit (C) is generated from a random seed.

19. The one or more non-transitory computer-readable media of claim 17 or claim 18 further storing instructions configured to, when executed, cause the at least one computing device to:

carry out a checking procedure by the second party to check at least the received garbled Boolean circuit and the first and second keys.

20. The one or more non-transitory computer-readable media of claim 19, wherein the checking procedure is based on commitments computed by the first party and sent to the second party. 21 . The one or more non-transitory computer-readable media according to any of claims 17 to 20, wherein the data indicating two copies of the garbled Boolean circuits are hashes of the garbled Boolean circuits.

22. One or more non-transitory computer-readable media storing instructions configured to, when executed, cause at least one computing device to:

receive first trading instructions from the first party;

receive first trading instructions from the second party;

exchange data over the communications interface between the first party and the second party using an oblivious transfer mechanism based on the first and second trading instructions;

the first and second parties determine that the first trading instructions are compatible the second trading instructions without revealing first trading instructions to the second party and without revealing the second trading instructions to the first party using the exchanged data; and

if the first trading instructions are determined to be compatible with the second trading instructions then executing a trade between the first party and the second party corresponding to the first and second trading instructions.

Description:
Secure Computation

Field of the Invention

The present invention relates to a system architecture for providing improved encryption and security technology and a secure computation and encryption protocol.

Background of the Invention

Trading and transaction systems implemented using computer technology allow different parties to trade or make other exchanges with each other. Such a system 5 is shown schematically in figure 1 . Several parties or counterparties 10, 20, 30 provide orders to a central trading venue 40. The central trading venue 40 may act as a specific counterparty for each order and execute trades directly with each party 10, 20, 30. The central trading venue 40 may match particular orders received from different parties, which indirectly trade through the central trading venue 40. For example, counterparty 1 may submit an order to the central trading venue 40 to buy a quantity of an instrument.

Counterparty 2 may submit an order to sell the same instrument. The central trading venue 40 may either directly match the two counterparties together, may publish particular orders to be taken up by other parties or may simply act as a counterparty on both orders resulting in the central trading venue 40 buying the instrument from counterparty 2 and selling it to counterparty 1 . However, the central trading venue 40 may impose certain rules, regulations, costs and conditions on the orders and trades that are submitted and executed. Counterparty trades add trading and bandwidth volume (two trades may be required rather than 1 direct trade between external parties). The central trading venue 40 may have limits on capacity, bandwidth and trading volumes. In all of these situations, orders may be placed electronically and trades carried out electronically within the trading servers of the central trading venue 40, which may have technical and resource limits on volumes.

In order to avoid some of these drawbacks and restrictions, individual parties 10, 20, 30 may set up bilateral agreements with each other. Whilst this avoids the drawbacks associated with a central trading venue 40, it may require additional requirements and individual conditions placed on each counterparty. In particular, because there is no central trading venue 40 to impose conditions or rules on trades, then each counterparty 10, 20, 30 may need to have greater trust in their trading partners. Furthermore, when one party enters into a transaction with another party 20, e.g. counterparty 1 wishes to buy a quantity of an instrument from counterparty 2, this typically requires both parties making their intentions clear to the other party in the form of a specific order or instruction. If this is accepted and instructions match, then both parties may be satisfied. However, if an instruction is made or an order is submitted that is not taken up by the other party, then the very fact of issuing the order provides information to the other party that may be of commercial and technical importance. For example, this may affect subsequent behaviour from the other party. For instance, if one party knows that another party wishes to buy a large quantity of an instrument, then they may decide to buy a quantity of the instrument as they could expect the price to rise. Similarly, if one party becomes aware that another party wishes to sell a particular instrument (i.e. from a received offer or instruction), then this could indicate that the price will fall and so the other party may try to sell the same or similar instruments leading to the first party having to accept a lower price (or the instruction may go unfilled).

Such bilateral agreements may include commitments not to use this information in this way, but policing of such agreements can be difficult and unreliable. In a broader sense and in the context that extends beyond financial transactions, similar problems may be encountered in systems where confidential information is exchanged if particular conditions are met but where it is not possible to provide an opportunity for others to obtain particular information or data without disclosing some or all details of those data in advance, whether or not the exchange or conditions are met. For example, a database of records or resources may be maintained and queries may be submitted by other parties. Submitting a request for a particular data item or resource may itself constitute useful or confidential information and so it may be important to be able to provide the particular data item without the database owner having knowledge of which particular data item was retrieved or to which party it was sent.

Therefore, there is required both a secure computation or exchange protocol and a trading or transaction system architecture with improved encryption and security technology that overcomes these problems and drawbacks. Summary of the Invention

There is provided a secure computation protocol that allows bilateral transactions between two parties to be conducted without requiring an intermediary, broker or counterparty. This secure computer protocol operates without human intervention and is rooted in computer technology. It is not possible for a human to implement any aspects of this protocol as a mental act or using paper and pencil as it relies on functions only available from a computer processor. These transactions may be financial transactions but may include other communications, especially where information, data, tangible or intangible assets may be exchanged or transacted.

Each party has an instruction forming in input. A first party generates two copies of a garbled Boolean circuit, each garbled circuit having input wires (for receiving the transaction information required or sent by the first party). The input wires of the first copy of the garbled circuit are decryptable by a first key. The input wires of the second copy of the garbled circuit are decryptable by a second key. An oblivious transfer protocol runs in which: The keys are provided by the first party to the second party; the second party provides their input (i.e. transaction order information); the second party uses the keys to compute the output of the garbled Boolean circuit. The second party sends data to the first party allowing the first party to determine the output. If the output indicates that the transaction can proceed (e.g. side input, the size value, instrument value and price limits are acceptable) then the trade completes. The different keys on the wires results in the two copies of the Boolean circuits being independent "encryptions" of the same identical circuit. Garbled Boolean circuits can only be generated and processed electronically within a computer environment.

There is also provided a trading system architecture for conducting bilateral trades or transactions. The trading system architecture is similarly implemented within a computer environment and receives trade or transaction instructions from each of two parties. Data is exchanged between the parties without revealing the details of the transactions using an oblivious transfer technique. From these data, both parties can determine whether or not a transaction between the parties can take place. However, if the transaction instructions are not compatible and/or do not match (for example both are "buy" transactions or the price of the instructions do not match within a tolerance) then neither party gains any knowledge of the other party's instructions. The transaction may take place where the instructions are compatible or match (completely or partially). In this case, each party may find out the transaction instructions of the other party. As the instructions are handled by a computer system then no individual or person, other than the originator of the trade instruction, has knowledge of the instruction details. This further improves the security of the architecture. In accordance with a first aspect there is provided a secure computation method for executing first instructions (or a first instruction) issued by a first party and second instructions (or a second instruction) issued by a second party, the method comprising the steps of:

generating by the first party a garbled Boolean circuit (C);

sending data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC 2 ) has input wires configured to receive the second instructions and associated with a second key (k[1 ]);

sending the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

the second party obtaining an output from the first garbled Boolean circuit (C) using the first key (k[0]);

the second party providing the second instructions to the input wires of the second copy of the garbled Boolean circuit (C) and obtaining an output from the second copy of the garbled Boolean circuit (GC 2 ) using the second key (k[1 ]);

the second party providing the first party with the output of the second copy of the garbled Boolean circuit (GC 2 ); and

executing the first and second instructions if the first and second parties determine from the outputs of the first and second copies of the garbled Boolean circuits (GC 2 ,GC 2 ) that the first and second instructions are compatible.

Preferably, the second instructions are encoded from a first input Y to a second input Y' according to:

Y'=L \ R

Where ^is / bits long, Y' is of length 2/ bits, L and R are both / bits long, L is chosen uniformly at random, and R=L®Y. This further improves security. This helps to prevent a selective-bit attack by either or both parties being malicious. Optionally, the oblivious transfer has a deterrent factor of ¼. In other words, an adversary trying to cheat would be caught with a probability of at least one in four. Other deterrent factors may be used. Raising the deterrent factor may involve the use of more garbled Boolean circuits.

Preferably, the first instructions and the second instructions include an indication (side ! , side 2 ) of the trades being an instruction to buy an instrument or to a sell an instrument. In other words, the instructions may be either a buy or sell (request or provide) instruction where buy instructions may match against sell instructions (or other transactions or exchanges).

Preferably, the first and second instructions define a size of the trade or transaction.

Optionally, the first and second instructions may include a trading instrument (instrumenti , instrument 2 ). The instruments may match, in which case the transaction or trade may take place.

Preferably, determining from the outputs may further comprise determining that the first instructions are trade instructions to buy the instrument and the second instructions are trade instructions to sell the instrument. The size of the trade of the first instructions and the second instructions may match or if they do not match then a portion of the trade may fill (complete). For example, if one instruction is a buy of 10 and another instruction is a sell of 20 then a trade of 10 may result (unless the party selling 20 has explicitly required that they receive no partial fills (i.e. their order is a "Fill or Kill" order).

Advantageously, the Boolean circuit (C) may be configured to:

compute instrument ! = instrument 2 , and sidei≠ side 2 (and/or sizei > size 2 ). Size may be an amount (e.g. trade volume) and side may define a buy or sell, for example.

Optionally, the first and second instructions may further include a trading limit. For example, trading limits may include only sell at or above a specific value or only buy at or below a specific value. According to a second aspect there is provided a system for executing first instructions (or a first instruction) issued by a first party and second instructions (or a second instruction) issued by a second party, the system comprising:

at least one processor; and

memory storing executable instructions configured to, when executed by the at least one processor, cause the apparatus to:

generate for the first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC 2 ) has input wires configured to receive the second instructions and associated with a second key (k[1 ]);

send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled Boolean circuit (C);

obtain an output from the second copy of the garbled Boolean circuit (GC 2 ) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC 2 );

determine from the outputs of the first and second copies of the garbled Boolean circuits (GC 2 ,GC 2 ) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties. This system and architecture provide the security and confidentiality of a central trading system (i.e. each counterparty cannot determine details of another party's requirements until a trade concludes) but is more computationally and bandwidth efficient. For instance, it does not require communications between three separate entities and the resultant duplication of processing (i.e. a first trade between counterparty 1 and the central trading system and a second opposing trade between the central trading system and counterparty 2). Furthermore, fewer items of data need to be transferred over computer networks with the same result. Preferably, the instructions may be executed as part of an application programming interface, API and more preferably, a secure API. According to a third aspect there is provided a trading system architecture comprising:

a communications interface for providing communications with a first party and a second party; and

at least one processor;

memory storing executable instructions configured to, when executed by the at least one processor, cause the trading system architecture to:

receive first trading instructions from the first party;

receive first trading instructions from the second party;

exchange data over the communications interface between the first party and the second party using an oblivious transfer mechanism based on the first and second trading instructions;

the first and second parties determine that the first trading instructions are compatible the second trading instructions without revealing first trading instructions to the second party and without revealing the second trading instructions to the first party using the exchanged data; and

if the first trading instructions are determined to be compatible with the second trading instructions then executing a trade between the first party and the second party corresponding to the first and second trading instructions. Preferably, the trading system may further comprise an application programming interface configured to exchange the data between the first and second parties.

Advantageously, the executable instructions may further cause the trading system architecture to:

generate for the first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit to the second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining the first instructions and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC 2 ) has input wires configured to receive the second instructions and associated with a second key (k[1 ]); send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer;

obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled

Boolean circuit (C);

obtain an output from the second copy of the garbled Boolean circuit (GC 2 ) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC 2 );

determine from the outputs of the first and second copies of the garbled Boolean circuits (GC 2 ,GC 2 ) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties.

Preferably, the first trading instructions and the second trading instructions may include an indication of a buy instruction or a sell instruction and a trade size.

Optionally, the first trading instructions and the second trading instructions may further include any one or more of an instrument identifier, a price limit, a toxicity offset and a mid-price mismatch tolerance.

According to a fourth aspect there is provided one or more non-transitory computer- readable media storing instructions configured to, when executed, cause at least one computing device to:

generate for a first party a garbled Boolean circuit (C);

send data indicating two copies of the garbled Boolean circuit (C) to a second party, wherein the first copy of the garbled Boolean circuit (GCi) has input wires defining first instructions issued by the first party and associated with a first key (k[0]) and the second copy of the garbled Boolean circuit (GC 2 ) has input wires configured to receive second instructions issued by the second party and associated with a second key (k[1 ]);

send the first key (k[0]) and the second key (k[1 ]) from the first party to the second party using an oblivious transfer; obtain for the second party an output from the first garbled Boolean circuit (C) using the first key (k[0]);

provide the second instructions to the input wires of the second copy of the garbled Boolean circuit (C);

obtain an output from the second copy of the garbled Boolean circuit (GC 2 ) using the second key (k[1 ]);

provide the first party with the output of the second copy of the garbled Boolean circuit (GC 2 );

determine from the outputs of the first and second copies of the garbled Boolean circuits (GC 2 ,GC 2 ) that the first and second instructions are compatible; and

if the first and second instructions are compatible then execute the first and second instructions if the first and second parties. the garbled Boolean circuit (C) is generated from a random seed.

The seed method is a way of generating a garbled circuit from a fixed random seed for a pseudorandom generator. The method works by having the first party generating both circuits from random seeds and just sending the hash to the second party. Then, for the circuit that is opened, the first party just sends the seed, and for the circuit that is evaluated the first party sends the actual circuit. In both cases, the second party compares this with the hash that is received. This reduces the amount of communication but raises computation requirements (since it is necessary to hash everything). This may be particularly useful for very low bandwidth communication channels.

Preferably, the one or more non-transitory computer-readable media may further store instructions configured to, when executed, cause the at least one computing device to:

carry out a checking procedure by the second party to check at least the received garbled Boolean circuit and the first and second keys. This further allows the second party to determine that the instructions are compatible.

Preferably, the checking procedure is based on commitments computed by the first party and sent to the second party. The second party carries out corresponding decommitments. A commitment is a cryptographic analog of putting a value in an envelope. After putting the value in the envelope the committing party can no longer change it but the receiver does not know anything about the value inside. A commitment is cryptographically implemented in numerous ways. In one example implementation a commitment may be calculated to a value x by HASH(x,r) where HASH is a cryptographic hash function (like SHA256) and r is a random string.

Optionally, the data indicating two copies of the garbled Boolean circuits may be hashes of the garbled Boolean circuits. In other words, the two copies of the garbled Boolean circuits may be sent or hashes of one (or both) may be sent instead.

According to a fifth aspect, there is provided one or more non-transitory computer- readable media storing instructions configured to, when executed, cause at least one computing device to:

receive first trading instructions from the first party;

receive first trading instructions from the second party;

exchange data over the communications interface between the first party and the second party using an oblivious transfer mechanism based on the first and second trading instructions;

the first and second parties determine that the first trading instructions are compatible the second trading instructions without revealing first trading instructions to the second party and without revealing the second trading instructions to the first party using the exchanged data; and

if the first trading instructions are determined to be compatible with the second trading instructions then executing a trade between the first party and the second party corresponding to the first and second trading instructions.

The methods described above may be implemented as a computer program comprising program instructions to operate a computer. The computer program may be stored on a computer-readable medium.

The computer system may include a processor such as a central processing unit (CPU). The processor may execute logic in the form of a software program. The computer system may include a memory including volatile and non-volatile storage medium. A computer-readable medium may be included to store the logic or program instructions. The different parts of the system may be connected using a network (e.g. wireless networks and wired networks). The computer system may include one or more interfaces. The computer system may contain a suitable operating system such as UNIX, Windows (RTM) or Linux, for example. It should be noted that any feature described above may be used with any particular aspect or embodiment of the invention.

Brief description of the Figures The present invention may be put into practice in a number of ways and

embodiments will now be described by way of example only and with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of a trading system, according to the prior art; FIG. 2 shows a schematic diagram of a bilateral trading system, given by way of example only;

FIG. 3 shows a sequence diagram of a method used within a trading system architecture, given by way of example only;

FIG. 4 shows a sequence diagram of an example trade executed within the trading system architecture of figure 3;

FIG. 5 shows a sequence diagram illustrating a further example trade;

FIG. 6 shows a flowchart of an example method used to carry out a secure computation protocol between two parties, given by way of example only; and

FIG. 7 shows a schematic diagram of the trading system architecture of figure 3. It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale. Like features are provided with the same reference numerals.

Detailed description of the preferred embodiments

Figure 2 illustrates schematically a trading system comprising a number (one or more) of bilateral relationships or systems. Each counterparty 10, 20, 30 may have one or more bilateral arrangements with the remaining counterparties. A counterparty (e.g.

counterparty 1 ) may have several potential counterparties and it may use a particular framework to trade with all of them. Orders may be sent out to different potential counterparties. For example, if counterparty 1 attempts to trade with counterparty 2 but the desired amount is not traded then counterparty 1 may send the unfilled remainder of a trade or instruction to counterparty 3. There may be two or more counterparties and bilateral systems, each operating under similar logic.

Figure 3 shows a sequence diagram illustrating a particular embodiment of a trading system architecture. This is a bilateral system in which a first party 10 trades with a second party 20. The secure bilateral trading system (SBTS) 1 10 and 1 10' are instances of processing logic enabling each party 10, 20 respectively to determine whether or not a trade may take place between the parties. In this example implementation, an application programming interface (API) provides an interface between the parties 10, 20. The architecture may be used to facilitate the bilateral arrangements described with reference to figure 2.

In the scenario shown in figure 3, the first party 10 submits a buy-order that does not find a match. Therefore, no trade takes place at this point. However, the second party 20 submits an order to sell, which matches the buy-order of the first party 10, which results in a match and trade between the parties. Importantly, before the match occurs, only the party submitting the order has any knowledge of the order instruction (e.g. what instrument will be traded, the quantity and direction of the order and possibly price limits). The system achieves this secure and confidential exchange of data by using oblivious transfer techniques. In other words, information is exchanged without the party that is the source of the information having knowledge of what has been transferred to the other party. This is analogous to a solution to the Millionaire's Problem.

The Millionaire's Problem was first specified by Yao in the early 1980s

(http://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_Pro blem). It describes a situation where two millionaires want to know who is the richest but neither wants to tell the other their exact wealth. Yao proposed an algorithm which allows them to determine who is the wealthier without either party revealing to the other what their actual wealth is. This is an example of secure multi-party computation in the field of cryptography.

The oblivious transfer (OT) protocol used in this embodiment allows a sender to transfers one of potentially many pieces of information to a receiver but does not know which piece (if any) has been transferred. The SBTS 1 10 has been built using a cryptographic library to form a Secure Computation API (SCAPI). Secure computation is the realisation of a function (encoded as a Boolean circuit) that takes inputs from two parties and, when executed, results in both parties seeing the same result, but neither party being able to deduce the other party's input into the function If either party attempts to cheat then there are mechanisms within the algorithm to detect the cheat attempt. In one example, SCAPI is used to securely determine the quantity traded and communicate the price of any trade.

Advantages of this system include cost savings as there is no requirement to build, host and support a separate market infrastructure e.g. electronic matching engine.

Therefore, the market can operate with lower or no brokerage charges. There may be a reduced market impact as only the counterparties to the trade know anything about the trade (post trade or exchange of information). In other words, pre-trade confidentiality may be achieved and only post-trade information being limited to the actual trading

counterparties. This is similar to a traditional dark pool but with lower processing requirements.

Each party may maintain greater control as the details of any rules of trading may be determined and negotiated between counterparties (rather than being set by an exchange or third party). Transparency may be maintained as conditions may not be liable to a central market changing rules secretly, cutting special deals with some participants, and/or selling trading data without permission, for example. Stability may be maintained as systems and processes (especially communication, logical and computing requirements) may not be held subject to a central exchange. These may include changes in connection details and requirements, API specifications (requiring code changes), charging models, connection fees, and brokerage rate changes, for example.

SBTS 1 10 supports at least two different order types; limit orders and mid-price orders. In one example, only one type is allowed per pair of SBTS instances. These can be configured as configuration files (e.g. YML) as follows:

party: circuit:

pricing: <LIMIT/MID> When using limit price orders, a match takes place if there are BUY and SELL orders for the same instrument, and the price on the BUY order is greater than or equal to the price on the SELL order. In this case a trade is generated with the price equal to the average of the price on the two orders (this may be known as "shared price improvement"). Alternative rules for deciding the price can also be used. The quantity traded may be the lower of the two orders.

For example:

Figure 4 shows a sequence diagram illustrating a limit price protocol. In this scenario orders are submitted that do not contain a tolerance and will be crossed strictly based on the bid price being greater or equal to the offer price. The resulting fill can be at the average of the two parties' orders (e.g. [mean(2.77 ,2.75)]). Other rules for generating the price can be used.

Another type of order is a mid-price order. When using mid-price orders, a match takes place whenever there are BUY and SELL orders for the same instrument with non- zero quantities. The size of the trade is the lower of the two order sizes and the price is the average of the mid prices supplied by each counterparty. For example,

A mid-price protocol allows both parties to submit their estimate of the fair mid-price of the market at the time of matching. The trade price is the mean of the two prices. This may be similar to the limit price protocol. The difference is that with the mid-price protocol there is no requirement that the buy order price is greater than or equal to the sell order price. In other words, the prices don't have to "cross" as they do for the limit price protocol. Mid-price mismatch tolerance may be an optional extra parameter that can be supplied by each party and which allows a potential trade to be rejected if the difference between the mid-prices on each order is too high. This would usually indicate that one of the prices was "wrong".

Toxicity offset is an optional parameter that may be agreed between two parties to correct for the relative toxicity of the trades between them. The size of the offset may be agreed offline and can be adjusted periodically (e.g. weekly) to ensure that trading between the two parties does not advantage either party over the medium term. In case of a disagreement on the offset there will be no trade.

Toxicity calculation allows parties to calculate a relative toxicity of the flow between two parties. This may involve calculating post-trade price change for every trade between the parties. This may be achieved by exchanging estimates of a fair market mid-price at a fixed interval (e.g. 60 seconds, five minutes, 10 minutes, etc.) following each trade. These estimates may then be used to derive the toxicity offset using an agreed formula. If either party fails to send a delayed mid-price then an alert may be sent to both parties. Toxicity is a measure of the post-trade mark-to-market of a trade. This is sometimes referred to as "decay". For example, Party 1 does a trade to buy 1 mio EURUSD from Party 2 at a price of 1 .2345. 60 seconds after the trade the mid-price in the market is 1 .2340. In this case the trade has decayed against Party 1 by 0.0005. Toxicity is usually aggregated over a large number of trades to obtain an estimate of the average cost/benefit of trading between two counterparties. The toxicity offset is used to correct for a systematic cost/benefit accrued when trading between counterparties. An example is shown schematically in figure 5, which describes:

1 . Party 1 submits a buy order with a mid-price of 2.77, a tolerance of 0.02 and an offset of 0.01 in their favour.

2. Party 2 submits a sell order with a mid-price of 2.78, a tolerance of 0.02 and an offset of 0.01 against them.

3. The mean mid-price = (2.77 + 2.78)/2 = 2.775 4. The mid-price difference = 2.78-2.77 = 0.01 , this is less than the tolerance (=0.02) so the trade can go ahead.

5. The toxicity offset value is agreed between the 2 parties and hence is applied to the trade price: 2.775-0.01 = 2.765. This trade is then notified back to both parties.

6. Finally 60 seconds after the trade each party sends the other party their estimate of the fair market mid-price.

Further technical details of the example system include the programming language being Java. Other programming languages may be used. The platform or operating system may be Linux or Windows, for example. CPU and disk capacity may be governed by the trading activity. SBTS 1 10 may also require disk space to store message logs and trade data. Preferably, counterparties may communicate using a virtual private network (VPN) or other secure communication channel, as the lagged mid-price exchange may be carried in the clear.

The trade may be communicated to parties using a FIX Execution Report message, for example. Further confirmation and settlement may occur outside of SBTS 1 10 using existing standard procedures.

In order to carry out order management, SBTS 1 10 may maintain an internal order book, which can hold a single resting (Good Til Cancelled - GTC) order per instrument, per client session. Each instrument may be represented by an integer value agreed in advance by both counterparties, e.g. instrument '1 ' might represent the Foreign Exchange currency pair - GBPUSD, trading British pounds for US dollars, or the five year on-the-run US Treasury note.

Parties may maintain the book using single order management messages as specified in the FIX 4.4 Protocol (see https://fixspec.com/FIX44). When an order status is changed, either through a trade taking place or as a result of one of the above requests, the party who owns the order may be sent an execution report with details of the trade done: (e.g. size, price etc.)

Orders may be in one of the following states:

Rejected New

Partially filled

Filled

Pending Cancel

· Pending Replace

Cancelled

Replaced

In the event that a trading session is disconnected, then a mass cancel of all active orders may take place.

The system may be configured so that all active orders are cancelled at an agreed end of day, or end of week time.

The following description is an example of a secure trading protocol, which may be used within the trading system architecture described above or implemented separately. The protocol involves two parties that wish to check whether to perform a trade. A detailed description of an example Boolean circuit used within the protocol is provided at the end of this description. The protocol may be used between more than one pair of parties and each party may be a part of more than one pair. This protocol may be summarised as each of the two parties having any of the following inputs:

An instrument value (optional in this example).

A side input (preferable in this example), which is a bit that is interpreted as either \buy" or \sell".

A size value (preferable in this example).

A price limit value (optional in this example).

A trade is possible if the two instrument inputs are equal (if instrument inputs are used), and the side inputs match (namely, one is a buy and the other is a sell), and the price limit of the seller is not greater than that of the buyer (if price limits are used). If a trade is possible then the functionality outputs the minimum size input and the average (for example) price limit. Otherwise it outputs 0 (i.e. an indication that the trade cannot be made). The secure computation protocol (e.g. part of an API) computes this functionality without disclosing any information except for the final output of the function. This means that the only information that a participant in the protocol gains about the input of the other party is information that can be deduced from the output of the functionality. For example, if the output of the protocol is 0, then the first party (P1 ) learns that one or more of the following events happened: (1 ) the instrument value of P2 is different to that of P1 ; (2) the side input of P2 is equal to that of P1 ; (3) the size value of P2 is 0; (4) the price limit of the seller is strictly higher than that of the buyer. P1 does not learn which of these events happened. Note that the release of this information is inevitable if it is required that P1 learns whether a trade is possible. The cryptographic protocol prevents any other information from being leaked.

The protocol (secure computation) may be implemented based on a generic protocol for secure computation. The protocol is "generic" in the sense that it can be used for computing any function. The protocol essentially computes a "program" that is described as a Boolean circuit. Namely, a circuit with Boolean gates, such as AND and NOT, and wires that pass Boolean values. The protocol can be used for securely computing any program that is described as a circuit. An example circuit is described at the end of this description.

The example protocol that is used is based on a protocol by Yao, and different subsequent optimizations. More about this protocol can be found, e.g., in [4]. The implementation is based on the SCAPI library [2]. Formal security proofs may be found in [3, 1 ]. The protocol is secure against a corrupt adversary that is controlling one of the participants. When considering possible adversarial behaviour, we consider three different possible levels of corruption:

Semi-honest adversaries execute the protocol that they are asked to run, but afterwards might try to deduce additional information from the messages that were received during the protocol. This model might be suitable for parties that are honest during the execution of the protocol but become corrupted at a later time, and might then try to examine their logs and deduce additional information from them. Malicious adversaries can behave arbitrarily during the execution of the protocol. This is the strongest level of corruption that has been specifically considered.

Covert adversaries might behave arbitrarily during the execution of the protocol, but try to avoid being detected as a dishonest party. For such an adversary we can define a deterrent probability of e, and assume that the adversary prefers not to cheat if it knows that the probability of the cheating being detected is at least e. This model, which was first defined in [1 ], might be very relevant for parties that have long lasting relationships and have a lot to lose if being exposed as cheaters. Protocols that are secure against malicious adversaries (the strongest level of corruption) are less efficient than protocols secure against semi-honest adversaries.

Protocols that are secure against covert adversaries are typically only slightly less efficient than protocols secure against semi-honest adversaries and offer a much better assurance to the participants. A particular deterrent factor of e = ¼ provides a good compromise.

Encoding the input of the second party provides additional security. This may be achieved by the second party splitting its input in the following way: If the original input of that party is a value /that is / bits long, it may use instead an input /of length 2/ bits, which is defined in the following way: Let Y' = L®R, where the length of both L and R is / bits. Then L is chosen uniformly at random, and R = L® Y. That is, the original input is equal to the exclusive-or of the two halves of the new input.

The circuit that is generated by a script expects to receive an input in this form. (The first operation that the circuit performs is computing the exclusive-or of the two halves of the input of the second party.) The script for generating the inputs receives the original input of the second party, and generates the double-length input for the circuit.

This protocol achieves a deterrent factor of e = ¼ (meaning that if the adversary tries to cheat it is caught with probability at least ¼). It is possible to get a higher deterrent factor at the cost of more computation; see [1 ].

The keys must be generated by a computer system to have sufficient size to prevent brute force attacks. Example bit lengths for these keys are 128, 256 and 512 but may be any length having sufficient strength to withstand an attack for the time in which the protected data is vulnerable to exploitation. Example protocol: (two-party computation of a function /):

Inputs: Party P^ has input x and party P 2 has input y, where |x| = |y| = L.

Auxiliary input: Both parties have the description of a circuit C that computes the function f(x, (y^ y 2 )) = f(x, y 1 0 y 2 ); in the protocol we set y = yi0y 2 . The input wires associated with x are w x , ... , w L and the input wires associated with y are w L+1 , ... , w 3L .

The protocol:

1 . P 2 chooses a random y 1 E R {0,l} lyl and defines y 2 = y Θ y . Denote Y the new input of P2 of length 2L and denote the ith bit of this input by Y t .

2. Pi generates 2 copies of a garbled circuit computing C; denote them GCi ; GC 2 . The version of the garbled circuit should not contain explicit output translation tables. Rather, every output gate should encrypt a random value, whose least significant bit is set to the appropriate value (0 or 1 ). [Use a Free-XOR circuit with a fixed AES key.]

3. Let k w ] . [0] and k^. [1 ] denote the 0 and 1 keys, respectively, associated with wire Wj in the j th garbled circuit obtained in the previous step (j = 1 ; 2).

4. For each i = 1, ... ,2L, parties P and P 2 run an oblivious transfer protocol (secure for covert with e= ^ or secure for malicious), as follows:

- Pi inputs two strings to the OT as sender: s 0 = (ki L+i [0], kw L+i [°]) and s 1 = {kl L+i [l], k* L+i [l])-

- P 2 inputs the bit Y t

- P 2 receives the string s Y . .

The oblivious transfers are run in parallel.

5. For i = 1, ... , L and j = 1, 2, party Pi computes commitments c^,. [0] = Com(/c^. [0]) and c^.[l] = Com(/c^.[l]). prepares vectors C^ C 2

j = ({c [0], c [l]} { t [0], l]})

(The pair {a, b} denotes the values placed in random order. The order is randomly chosen independently for each pair.)

6. Pi sends Com ! ; Com 2 ; GCi ; GC 2 to P 2 . (If communication turns out to be significant; the seed method for generating garbled circuits can be used).

[ALL COMPUTATIONS AND MESSAGES SENT UNTIL THIS POINT CAN BE RUN

IN PARALLEL.]

7. Party P 2 chooses a random index γ e R {1, 2} and sends γ to P 8. Pi sends P 2 all of the keys for the input wires (saying which is a 0 key and which is a 1 key) in the garbled circuit G ; for j≠ y. In addition, for j≠ y, it decommits to

Corri j .

9. P 2 checks that everything that it received is in order. That is, it checks

- That the decommitments are all correct (this also gives the keys on P s input wires w lt .... w L );

- That the keys received in the oblivious transfers earlier match the appropriate keys that it received in the opening (i.e., if it received (kl L+i [b], k„ L+ .[b]) in the i th oblivious transfer, then it checks that kl L+ .[b] from the oblivious transfer equals the keys it received in the opened circuits on that wire);

- That the keys it received for all input wires in circuit GC j ' ≠ Y) indeed decrypt the circuit (when using the received mappings), and the decrypted circuits is C. If all the checks pass, it proceeds to the next step. If not, it outputs corrupted ! and halts. In addition, if P 2 does not receive this message at all, it outputs corrupted ! .

10. Pi decommits to the input keys associated with its input for the unopened circuit GC Y . That is, for i = 1, ... , L, party Pi decommits to c^. [ j], where ; is the i th bit of P s input. (Of course, P also says which of the pair is the one being decommitted to.) If any decommitment is invalid, then P2 outputs abor^ and halts.

1 1 . P 2 uses the keys to compute GC Y , and outputs the result. If the keys are not correct (and so it is not possible to compute the circuit), or if P 2 does not receive this message at all, it outputs aborts

12. P 2 sends the output to Pi together with the appropriate garbled value on the output wires. That is, if the key obtained in the i th output wire is k then P 2 sends k l to P

13. Pi determines the output based on the k l values it receives. If it receives any incorrect value (i.e., not one of the values in the output gate), then it outputs abort 2 .

Note that steps 8-10 are actually a single step of P 7 sending a message to P 2 , followed by P 2 carrying out a computation. If during the execution, any party fails to receive a message or receives one that is ill-formed, it outputs abort; (where Pi is the party that failed to send the message). This holds unless the party is explicitly instructed above to output corrupted; instead (as in Step 9).

Figure 6 shows a schematic diagram of the example secure protocol 200 at a high level. Figure 7 shows a schematic diagram of the trading system architecture 300. The trading system architecture may execute the secure protocol described in detail or variations of it. Each party 10, 20 may operate a computer system or processor 310 having memory 315 to store computer implemented instructions and in this particular embodiment, an API client. The processors 310 communication with each other over a network 330 according to the API definition (e.g. SCAPI). This may be a secure communications network or a VPN operating over a non-secured communications channel such as the public internet, for example. References

[1 ] Yonatan Aumann and Yehuda Lindell. Security against covert adversaries: Efficient protocols for realistic adversaries. J. Cryptology, 23(2):281 {343, 2010.

[2] Yael Ejgenberg, Moriya Farbstein, Meital Levy, and Yehuda Lindell. Scapi: The secure computation application programming interface. Cryptology ePrint Archive, Report 2012/629, 2012. http://eprint.iacr.org/.

[3] Oded Goldreich. Foundations of Cryptography: Volume 2, Basic

Applications. Cambridge University Press, New York, NY, USA, 2004.

[4] Yehuda Lindell and Benny Pinkas. A proof of security of Yao's protocol for two-party computation. J. Cryptology, 22(2):161 {188, 2009.

An example Circuit used in the Protocol

The following describes an example Boolean circuit that is used in the protocol for computing the described function. Other Boolean circuits may be used.

The protocol can be used for computing any other function. In that case the circuit should be changed to compute the desired function.

Parameters and Inputs

The circuit depends on the following parameters:

instrumentlength: The length in bits of the "instrument" input. This value is an integer greater than or equal to 0. A value of 0 means that no instruments are used. We also denote this value as IL in the sequel.

sizelength (n): The length in bits of the "size" input. This value is an integer.

Zero size order may be used as distractors. We also denote this value as n in the sequel.

pricelimitlength: The length in bits of the price limit inputs. These are the "max price" input for the buyer, and the "min price" for the seller. This value is an integer greater than or equal to 0. We also denote this value as PLL in the sequel. A value of 0 means that no price limits are used.

The input to the protocol contains the following items:

Instrument: Represented as an integer number of length instrumentlength bits. This input is not used if instrumentlength=0.

Side: Either buy or sell. This input is represented as a single bit. Its value is 0 for a "buy, and 1 for a "self.

Size: A integer value of length sizelength bits, i.e., in the range 0, ... , B, where b is defined as B = 2 sizelen ^ th - l = 2 n - 1 . Typical values for B are 15, and 63.

pricelimit: A value of length pricelimitlength bits, i.e. in the range [0, P] , where P is defined as P = 2V ricelimitlen e th - 1 = 2 PLL - 1 .

The Function that is Computed

The function is computed between two parties, Pi and P 2 , with input instrument^,, side b , size^and pricelimit^ for b = 1, 2, respectively.

The computed function is

- min (size^, size!) if

- instrument-^ = instrument 2 ,

- and side 1 ≠ side 2 ,

- and pricelimit 1+sidei ≥ pricelimit 2 - sidei (This ensures that the circuit always requires that the buyer's limit is greater than or equal to the seller's limit. We're only concerned here about the case where a transaction is about to take place, so P 2 's intent is the opposite of that of P )

An easier way of computing this condition is to compute whether pricelimi^ > pricelimit 2 , and then make the decision based on this value xored with an appropriate bit (and also make sure that if the values are equal then the condition holds).

- 0 otherwise (i.e., if instrument 1 ≠ instrument 2 or if side 1 = side 2 ox if pricelimit 1+sidei < pricelimit 2 _ sidei ).

Circuit design: high level

The actual circuit computing the function operates in the following way:

1 . Computes whether size 1 > size 2 . This is done from the msb to the Isb. Denote the result bit as c. 2. For each bit i of the n bits of the size values, use a multiplexer which outputs the i th bit of size 1 if c = 0, and the i th bit of size 2 otherwise. Call the resulting n bits as tn-l> to-

3. Computes a bit d which is 1 if and only if

instrument 1 = instrument 2 (if instruments are used, i.e., instrumentlength > 0

and side-L ≠ side 2

and pricelimit 1+sidei ≥ pricelimit 2 _ sidei (if price limits are used, i.e., pricelimitlength > 0).

4. Set the output as n bits, defined as out; = t t AND d, and (if pricelimites are used) prints the minimum of the two prices (i.e., the seller's pricelimit).

Circuit design: low level

1 . Set the bit c to 1 iff x > y.

Let the inputs be χ = χ 0 - x n -i and y = y 0 - y n -i- (Note that bit 0 is the MSB. This is required due to the structure of the circuit.) Denote c as the result. For i from 0 to n - 1 let dj = x; Θ y; . (d; denotes whether the two bits are different.)

i denotes whether the input bits up to location i (not including) were all equal. Po is set to 1 .

For i from 1 to n - 1 let p { = p { _ AND NOT (d^ .

(Note that p t θ Pi_i is equal to p t _ x AND d^).

c 0 = d 0 AND x 0 .

For j from 1 to n - 1 let q = c t _ x θ(ρ; AND d t AND x t .

(This last step can be improved to

For j from 1 to n - 2 let q = c _ x θ((Ρ ί θΡί+ι) AND x .. In addition, handle location n - 1 separately. We will not use this improvement.)

Let c = c n _ .

Note that we can use XORs between the different clauses since at most one of them will be 1 . (If d n _ t = · ·· = d i+1 = 0 and dj = 1 , then all clauses except for clause i are definitely equal to 0.)

2. A multiplexer which outputs the ith bit of x if c = 0, and the ith bit of y otherwise.

Denote the output as t. For i = 0 to n - 1 set

t t = x t XOR ((X; XOR y t ) AND c) 3. Computes a bit d which is 1 if and only if instrument ! = instrument 2 and also side ≠ side 2 and pricelimit 1+sidei ≥ pricelimit 2 - sidei

This is done in the following way:

(AS BEFORE, but with a flexible number of bits) instrument- ! is of length IL bits. Denote its bits as instrumenta l ^,■■■ , instrument 1 0 . Do the same for instrument 2 .

Compute

d-i = (instrument 1j i- 1 XOR instrument 2 IL _ 1 ) OR ■■■ OR (instrument 1 0 XOR instrument 2 0 Compute d t = NOT^). (This bit is 1 iff instruments equal to instrument 2 .) Compute d 2 = side t XOR side 2 .

If price limits are not used:

Compute d = d t AND d 2 .

If price limits are used:

Compute whether pricelimit x > pricelimit 2 . This is done as in item 1 . Denote the output bit as d 3 .

Set d 4 = d 3 ® side 1 (i.e., if P is the buyer do not change d 3 , otherwise reverse it.)

Compute d 5 which is 1 iff pricelimit x = pricelimit 2 . (Computed as in the _rst bullet point.) (We could have made the circuit smaller by computing in the first step > instead of > but I prefer not to change the circuit too much at this stage.)

Compute d 6 = d 4 0R d 5

Compute d = d 1 AND d 2 AND d 6 .

4. If price limits are not used, set the output as n bits, defined as outi = f,

AND d.

For i = 0 to n - 1 do outi = t t AND d.

5. If price limits are used set the output length to be

m = n + pricelimitlength bits

Compute a multiplexer which outputs the minimum of the two price limits. I.e, outputs ith bit of pricelimiti if d 3 = 0, and the ith bit of pricelimit 2 otherwise.

Pi = pricelimit l i XOR ((pricelimit l i XOR pricelimit 2 i ) AND d 4 ) For ί = 0 to n - 1 do outi = AND d.

For ί = 0 to pricelimitlength— 1 do out n+i = p n+i AND d.

(Variant which does use instruments)

Use the same circuit as above, but in Step 4 do not check whether instrument = instrument^ Namely, do not implement the first and third bullet points. Detailed circuit design

Inputs: Set the following inputs:

If instruments are used then set P1 B to be IL. Otherwise set P1 B to be 0.

If instruments are used then let wires 0, ... , IL - 1 contain the bits of instrument, where wire 0 is the msb.

Let wire P1 B denote side t .

Let wire PIS + \, P1B + n be the bits of size 1 , where wire P1 B + 1 is the msb. If price limits are used then set P1 L to be P1 B + 1 + n. Let wires Pll, ... , P1L + PLL - 1 be the bits of pricelimi^, where wire P1 L is the msb. (PLL is the length of the price limit.)

If price limits are not used then let INSTRUMENTSP2 be equal to P1 B+1 +n, otherwise let INSTRUMENTSP2 be equal to P1 L + PLL.

If instruments are used then set P2B to be INSTRUMENTSP2+IL. Otherwise set P2B to be INSTRUMENTSP2.

If instruments are used then let wires INSTRUMENTSP2,...,INSTRUMENTSP2 +

IL - 1 contain the bits of isntrument 2 , where wire INSTRUMENTSP2 is the msb.

Let wire P2B denote side 2 .

Let wire P2B + 1 ,...,P2B + n be the bits of size 2 , where wire P2B + 1 is the msb. If price limits are used then set P2L to be P2B + 1 + n. Let wires P2L,...,P2L + PLL - 1 be the bits of pricelimit 2 , where wire P2L is the msb. (PLL is the length of the price limit.)

If price limits are not used then set INPUTSIZE=P2B+n+1 . If price limits are used then set INPUTSIZE=P2L+PLL.

Computation of Step 1 Set the bit c to 1 iff size t > size 2 ..

Wires INPUTSIZE to INPUTSIZE+n-1 will contain the Rvalues.

Wires INPUTSIZE+n to INPUTSIZE+2n-1 will contain the p;values.

Wires INPUTSIZE+2n to INPUTSIZE+4n-1 will contain temporary values.

Wires INPUTSIZE+4n to INPUTSIZE+5n-1 will contain the ^values.

For i=0 to n-1 set wire INPUTSIZE+i to (wire P1 B+1 +i XOR wire P2B+1 +i).

djvalues)

Set wire INPUTSIZE+n to 1 . (p 0 values)

For i=1 to n-1 set wire INPUTSIZE+n+i to (wire INPUTSIZE+n+i-1 AND NOT(wire INPUTSIZE+i-1 ). (Note that i = 0 is not used.)

For i=1 to n-1 set wire INPUTSIZE+2n+i to (wire INPUTSIZE+n+i AND wire INPUT- SIZE+i). ( j AND d ) (Note that i = 0 is not used.) For i=1 to n-1 set wire INPUTSIZE+3n+i to (wire INPUTSIZE+2n+i AND wire P1 B+1 +i). (Previous temporary values AND x t .) (Note that i = 0 is not used.)

Set wire INPUTSIZE+4n to wire INPUTSIZE AND wire P1 B+1 .

For i=1 to n-1 set wire INPUTSIZE+4n+i to (wire INPUTSIZE+4n+i-1 XOR wire INPUT-SIZE+3n+i).

Set c to be wire INPUTSIZE+5n-1 .

Computation of Step 2 A multiplexer based on the value c, between the values in wires P1 B+1 ,...,P1 B+n and wires P2B+1 ,...,P2B+n.

This step uses temporary variables in wires INPUTSIZE+5n to INPUTSIZE+7n-1 . The output is in wires INPUTSIZE+7n to INPUTSIZE+8n-1 .

For i=0 to n-1 , set wire INPUTSIZE+5n+i to (wire P1 B+1 +i XOR wire P2B+1 +i). For i=0 to n-1 , set wire INPUTSIZE+6n+i to (wire INPUTSIZE+5n+i AND wire INPUTSIZE+5n-1 ).

For i=0 to n-1 , set wire INPUTSIZE+7n+i to (wire P1 B+1 +i XOR wire

INPUTSIZE+6n+i).

Computation of Step 3 Computes a bit d which is 1 if and only if instrumentl = instrument2 and also sidel is not equal to side2. (Assuming that instruments are used.) Denote by TBASE the value INPUTSIZE+8n.

Set the wire TBASE to be equal to wire P1 B XOR wire P2B. (Sides are different) Set d and d^o be TBASE.

If instruments are used then

For i from 0 to IL-1 set wire TBASE+1 +i to (wire i XOR wire INSTRUMENTSP2+i).

Set wire TBASE+IL+1 to (wire TBASE+1 OR wire TBASE+2).

For i from 2 to IL-1 , set wire TBASE+IL+i to (wire TBASE+IL-1 +i OR wire

TBASE+1 +i).

Set wire TBASE+2 * IL to NOT(wire TBASE+2 * IL-1 ).

Set wire TBASE+2 * IL+1 to (wire TBASE AND wire TBASE+2 * IL).

set d 2 to be equal to TBASE+2 * IL+1 .

Set wire TBASE+2 * IL+2 to be equal to wire d1 AND wire d 2 .

Set d to be TBASE+2 * IL+2.

(Computing whether pricelimi^ > pricelimit 2 )

Let TEMPBASE = TBASE+2 * IL+3.

Wires TEMPBASE to TEMPBASE+PLL-1 will contain the ddi values.

Wires TEMPBASE+PLL to TEMPBASE+2PLL-1 will contain the pi values.

Wires TEMPBASE+2PLL to TEMPBASE+4PLL-1 will contain temporary values. Wires TEMPBASE+4PLL to TEMPBASE+5PLL-1 will contain the ci values.

For i=0 to PLL-1 set wire TEMPBASE+i to (wire P1 L+i XOR wire P2L+i).

(devalues)

Set wire TEMPBASE+PLL to 1 . (p 0 values)

For i=1 to PLL-1 set wire TEMPBASE+PLL+i to (wire TEMPBASE+PLL+i-1 AND

NOT(wire TEMPBASE+i-1 ). (Note that i = 0 is not used.)

For i=1 to PLL-1 set wire TEMPBASE+2PLL+i to (wire TEMPBASE+PLL+i AND wire TEMPBASE+i). ( jAND dd ) (Note that i = 0 is not used.)

For i=1 to PLL-1 set wire TEMPBASE+3PLL+i to (wire TEMPBASE+2PLL+i AND wire P1 L+i). (Previous temporary values AND x t .) (Note that i = 0 is not used.)

Set wire TEMPBASE+4PLL to wire TEMPBASE AND wire P1 L.

For i=1 to PLL-1 set wire TEMPBASE+4PLL+i to (wire TEMPBASE+4PLL+i-1 XOR wire TEMPBASE+3PLL+i).

Set d 3 to be wire TEMPBASE+5PLL-1 .

Set wire TEMPBASE+5PLL to wire TEMPBASE+5PLL-1 (d 3 ) XOR wire P1 B (recall,

P1 B=side 1 ).

Set d 4 to be wire TEMPBASE+5PLL.

Check if pricelimit 1 = pricelimit 2 .

Set TBASEL to TEMPBASE+5PLL.

For i from 0 to PLL-1 set wire TBASEL+1 +i to (wire P1 L XOR wire P2L).

Set wire TBASEL+PLL+1 to (wire TBASEL+1 OR wire TBASEL+2).

For i from 2 to PLL-1 set wire TBASEL+PLL+i to (wire TBASEL+PLL-1 +i OR wire

TBASEL+1 +i).

Set wire TBASEL+2 * PLL to NOT(wire TBASEL+2 * PLL-1 ).

Set d 5 to be wire TBASEL+2 * PLL.

Set wire TBASEL+2 * PLL+1 to be wire TEMPBASE+5PLL-1 OR TBASEL+2 * PLL. Set d 6 to be wire TBASEL+2 * PLL+1 (d 5 OR d 6 ).

Set wire d 6 + 1 to be (wire d AND wire d 6 ).

Set d to be wire d 6 + 1 :

Computation of Step 3.5 Compute a multiplexer which outputs the minimum of the two pricelimits. I.e, outputs the ith bit of pricelimitl if d 3 = 0, and the ith bit of

priceZimit 2 otherwise. A multiplexer based on the value d 3 , between the values in wires P1 L,...,P1 L+PLL-1 and wires P2L,...,P2L+PLL-1 . Set PLD to be d + 1 .a

For i=0 to PLL-1 , set wire PLD+i to (wire P1 L+i XOR wire P2L+i).

For i=0 to PLL-1 , set wire PLD+PLL+i to (wire PLD+i AND wire d 3 ).

For i=0 to PLL-1 , set wire PLD+2 * PLL+i to (wire PLD+PLL+i XOR wire P1 L+i) Set MINVAL to PLD+2 * PLL. The minimum value is in wires MINVAL to

MINVAL+PLL-1 .

Computation of Step 4

(Always) Define the first n output bits as ti AND d.

If price limits are not used then

Denote OUTBASE as d+1 . The output wires are wires OUTBASE to OUTBASE+n-

1 .

For i = 0 to n-1 set wire OUTBASE+i to (wire INPUTSIZE+7n+i AND wire d).

If price limits are used then

Denote OUTBASE as MINVAL+PLL. The output wires are wires OUTBASE to OUTBASE+n+PLL-1 .

For i = 0 to n-1 set wire OUTBASE+i to (wire INPUTSIZE+7n+i AND wire d).

For i = 0 to PLL-1 set wire OUTBASE+n+i to (wire MINVAL+i AND wire d).

It is noted that in order to handle the described complexities of the secure computation method then the use of computer systems and hardware is essential.

As will be appreciated by a skilled person, details of the above embodiment may be varied without departing from the scope of the present invention, as defined by the appended claims.

For example, a trade may be an exchange of information between two parties. The trade does not need to be a buy and sell trade but may involve swaps (financial or otherwise) or other events. More than two parties may be involved in a transaction or trade. Whilst bilateral trading (i.e. without the use of an intermediary or exchange) is described, the system, method and architecture may be operated by a third party that is or is not directly involved in each trade or transaction. The use of an API is described but the architecture may use other interfaces (both secure and insecure). Trades, transactions or exchanges of information may be between two distinct entities (e.g. banks, or financial or other institutions) or may be internal transactions within the same entity or organisation. Commission or fees may or may not be charged. Many combinations, modifications, or alterations to the features of the above embodiments will be readily apparent to a skilled person and are intended to form part of the invention. Any of the features described specifically relating to one embodiment or example may be used in any other embodiment by making the appropriate changes.