CÁLCULO DE CADENA DE TRANSMISIÓN GENERADORA

To hide the fact the other states are the same can be achieved, but this will require additional latency. The same model as Section 5.4.2 is used, with a step added before a server receives the obfuscated LUT. A server must first ask for a subset of rows–in random order–it wants in the obfuscated LUT. Therefore, instead of the obfuscated LUT containing all possible states for the server, it only has a subset (now known as a small obfuscated LUT). This also reduces the amount of data being sent over the network. By enforcing varying subsets, the column approach12_{to see if the other servers’ states remained the}

same cannot work as efficiently (if at all). The enforcement of varying subsets can be done by the server creating the small obfuscated LUT, by refusing to

10_{The user can set the seed values, or the fragment servers could securely agree/generate a}

new seed at given intervals.

11_{A shuffle function could be used as well, where the random number defines how the shuffle}

should occur.

send the same rows if some condition is met, such as two requests for the exact same rows.

The final step is to hide all of the possible outputs of the small obfus- cated LUT apart from the resulting reduced state. To achieve this, each row in the small obfuscated LUT now uses different random values for r0 and r1

(recall thatr0is XORed over the row, andr1 is a bit shift index). The fragment

server sending the index and whether the bit needs to be flipped now receives an index number for the correct row in the small obfuscated LUT, which it uses to get the correctr0 and r1 values. Note that this index number is not a state

value, and will change even if the same state value is being reduced. So now we have two transfers (one RTT) between each fragment server, represented in Figure 5.13. Note that the flow will be shown visually in Section 5.5.1, which will help explain this concept.

At this point, the small obfuscated LUT is protected, where the random values could be thought of as secret keys. However, Hypothesis 3 requires that only encoding is to be used for achieving privacy-preserving computation. Classifying the simple XOR and rotation functions as a form of encryption is subjective. With 64 possible states for each reduction, the XOR value will be between 0 and 63, while the rotate value will be between 0 and 7. With so few possibilities, trying all combinations requires little effort–knowing which is correct is the challenge. Therefore, this technique can be considered a form of Privacy-Preserving Encoding, as it is too weak to be encryption.

Given the complexity of this model (known as the enhanced privacy model), the Pi-Calculus equations are defined for a three server model and are not dynamic. The sameLookupprocess can be used, as described in Equation 5.8. To generate the small obfuscated LUT,SubLookupis defined in Equation 5.14. This waits for the list of obfuscated states and creates the small obfuscated LUT accordingly. The process then waits to receive the row indexi that this frag- ment server will use to get its reduced state. The value i is sent to the other server. It then applies a different random value r0 and a random shift r1 to

each row using the pseudo-random number generator rgen to the small ob- fuscated LUT. The small obfuscated LUT is sent to the other server, before waiting to receive the index value and bit flip value from that server, for row iof the small obfuscated LUT this server will receive.

P1 P9 P17 P r ocess P2 R eduction 1 _P4 P3 P5 R eduction 2 _P7 P6 P8 R eceiv e P r ocess P10 R eduction 1 P12 P11 P13 R eduction 2 P15 P14 P16 R eceiv e P r ocess P18 R eduction 1 P20 P19 P21 R eduction 2 P23 P22 P24 R eceiv e Figure 5.13: Three serv er P etri Net for the FRIBs en hanced priv acy mo del

SubLookup(table_name, key, server_in, server_out, index, r_gen) =key(state, result). server_in(ostate0, ... , ostatex). index(i). server_out < i > .

(state, ostate0, ... , ostatex, table_name) map

−−→(sub_table). (sub_table)−−−−−→ran(rgen) (rsub_table).

server_out < rsub_table > |server_in(rindex, rf lip). result < i, rindex, rf lip > .

SubLookup(table_name, key, server_in, server_out, r_gen)

(5.14)

The opposite process of SubLookup is the new definition for SubReduce in Equation 5.15. This process obfuscates the server’s state, and randomises it usingrgen and the row indexriused by the other server (row index ensures the rightr0 andr1 values). The output is the index in the row and whether the bit

needs to be flipped, which is sent to the other server through channelserverout. The second part of this process is to receive the small obfuscated LUT. First, it uses a different LUT to get a different obfuscated value, obf_state0, and

generates a random array of possible obfuscated states, including obf_state0

at index i. The array is sent to the fragment server, which has the full LUT for this server (received in aSubLookup process). The small obfuscated LUT is received through channel serverin, and returned.

SubReduce(server_in, server_out, table, index, state_in, r_gen) = state_in(state, result).table < state, c1 > .c1(obf_state).

(obf_state)−−−−→rstates (i, ostate0, ... , ostatex). server_out < ostate0, ... , ostatex > .

index < i > . server_in(ri).(obf_state)−r−−−gen,ri→(rindex, rf lip). server_out < rindex, rf lip > |server_in(rsub_table).

result < rsub_table > .

SubReduce(server_in, server_out, table, state_in, r_gen)

The Reduceprocess has three arguments, where server1 is a channel to a Sub-

Reduce process, server2 is a channel to a SubLookup process, and statein is the input/output channel for the process. Upon receiving a state to reduce, the state is sent to each server through either SubReduce or SubLookup. The values received are a row index, bit flip value, and a randomised small obfus- cated LUT. Using the row indexiwhich is the server’s state, the reduced state can be retrieved by subtable[i][rindex]⊕rf lip.

Reduce(server1, server2, state_in) =

state_in(state, result).

server1 < state, tr1 >|server2 < state, tr2 > .

tr1(subtable)|tr2(i, rindex, rf lip).

(i, rindex, rf lip, subtable)−−→map (new_state). result < new_state > .

Reduce(server1, server2, state_in)

(5.16)

A fragment server can then be defined in Equation 5.17. It requires two LUTs to obfuscate the server’s state for communicating with the other two servers using the Lookup process. A SubLookup and SubReduce process is needed to communicate with the other fragment servers. Finally, theReduceandProgram processes are required.

F ragmentServer(server1−0, server0−1, server2−0, server0−2,

table_r_name, table_0−1_name, table_0−2_name, r_gen1,

r_gen2) =

Lookup(table_0−1_name, table0−1)|

Lookup(table_0−2_name, table0−2)|

SubLookup(table_r_name, server2, table0−2, server0−2, server2−0,

index, r_gen2)|

SubReduce(server1−0, server0−1, table0−1, index, server1, r_gen1)|

Reduce(server1, server2, rstate)|P rogram(rstate)

Now, three fragment servers can be setup in parallel, as shown in Equation 5.18, to execute an arbitrary function/program over the fragmented data.

Compute=

F ragmentServer(server1−0, server0−1, server2−0, server0−2,

“table200,“table0−100,“table0−200, r_gen1, r_gen2)|

F ragmentServer(server2−1, server1−2, server0−1, server1−0,

“table000,“table1−200,“table1−000, r_gen2, r_gen0)|

F ragmentServer(server0−2, server2−0, server1−2, server2−1,

“table100,“table2−000,“table2−100, r_gen0, r_gen1)

(5.18)

During a reduction step, a fragment server only learns its new state, a list of possible states for one fragment server (ostate0, ... , ostatex), and no infor- mation about the other fragment server. It learns no information, because all it receives is an index into the correct row, and whether to flip the bit. This is not enough information to determine the server’s state or if the state has changed.