EL APRENDIZAJE DEL ESTUDIANTE

Data is sent between the fragment servers during processing. These channels need to be protected from eavesdropping to stop resulting states from being captured. Any encryption scheme can be used, but for performance, a sym- metric scheme such as AES is recommended. For most implementations, it

would be possible to utilise a transport layer security library when setting up the connection.

5.6 Summary

Two core models have been presented for FRIBs in this chapter: one focused on performance, and the other on privacy, known as the performance model and the enhanced privacy model respectively.13 _{The enhanced privacy model}

is the primary model, where a fragment server does not learn any information about states of the other fragment servers, and no patterns can be observed. This allows the LUTs to be reused, which is a challenge for most multi-party computation techniques. However, the reusability comes at the cost of the data not being protected by a secret key, like encryption, as retrieving all the fragments from each server will reveal the data. The other cost is each re- duction request takes the largest RTT between all fragment servers, where the performance model halves this and sends less data over the network. The prac- ticality can be estimated by network latency times, as lookup and processing requires little overhead. This means the fragment servers will spend most of their time waiting for network transfers, allowing for parallelisation to improve performance even with a single processor.

13_{The model using dedicated reduction servers would not be used in practice, and was only}

given as a form of explanation. It was also an important step in researching this scheme, and the basis of the original paper [23].

6

Lookup Table Design

The system model for the Fragmenting Individual Bits (FRIBs) scheme was defined in Chapter 5 but did not describe the lookup operation or how the Lookup Tables (LUTs) obtain fragmented results. This chapter will use a three-server model with the XOR fragment algorithm (bit = FA⊕FB⊕FC) to further elaborate FRIBs. Simple functions such as addition and multi- plication are described, while redundancy and randomisations techniques are introduced. Note that because FRIBs uses a simple lookup to compute over data, there are many more possibilities for what an LUT defines than what is given in this thesis.

6.1 Obfuscating States

With the performance or enhanced privacy model (described in Sections 5.4.1 and 5.4.3 respectively), because each fragment server performs its own reduc- tion, the possible states of the other servers are known. For example, if one fragment server has the state 1011001 ((1⊕0)⊕1), then the other fragment servers will have the same order of operations; therefore, 1011011 is not a pos- sible state. The result LUT can be thought of as a collection of mini result LUTs, that can be generated for each set of possible states. For this chapter, the result LUT will consist of one order of operations unless otherwise stated. The representation of Table 6.1 in memory can be a 64-bit number, where the least significant byte is index zero. To perform a lookup, the state is compared against all entries until its index is found. Another way of representing this

Table 6.1:Obfuscated states, mapping to the

index. Index State 0 1101011 1 11011011 2 10101 3 110101 4 101011 5 1011011 6 101101 7 1101101

Table 6.2:Obfuscated states, mapping to multiple values.

Index State Obfuscated States

0 11011011 14, 22, 0 1 1101101 20, 7, 3 2 1101011 9, 21, 8 3 110101 13, 16, 15 4 1011011 1, 23, 5 5 101101 11, 17, 18 6 101011 6, 10, 19 7 10101 4, 12, 2

LUT is by keeping the order of the states as per Table 6.2 (but with one obfuscated state); therefore, the LUT can be a 24-bit number, where the least significant three bits are index zero. Each index would contain a value between zero and seven (which is the obfuscated state), but a challenge is knowing the index of the state quickly. If all the operations are removed and 11 is converted back to 0, then 110110112 →< 11,11,11 >→ 0002 ≡ 0, or 10110112 →<

1,11,11 >→ 1002 ≡ 4. This saves on the amount of memory and storage

required for all the mini result LUTs. Table 6.2 can be represented the same way, except 3×5-bits are required per index, in this case requiring 120 bits. With one obfuscated state per fragment state, four operations require 32×5 bits, or 20 bytes. Increasing the number of operations to eight requires 29_×9

bits. The number of mini result LUTs depends on the number of different state forms that can be reached. For example, if only addition and multiplication operations are required, many state forms (order of operations) will not be reached.

For the performance model, a different set of result LUTs is used for each fragment server; therefore, with three servers, two obfuscated states are ob- tained and sent to their corresponding fragment server. For example, fragment server A would obfuscate its state using an obfuscation LUT for fragment server B (the result is sent to fragment server B), and obfuscate its state again but with an obfuscation LUT for fragment serverC.1 _{When a fragment}

server receives the two other obfuscated states, it can get the index into its result LUT. Once again, mini result LUTs can be used because the state form is known–keeping key sizes small. The result LUT is actually a 3-dimensional array where each state is part of the key. If a fragment server’s own state is s0 and the obfuscated states are s1 and s2, then the result can be accessed by

s0×n2+s1×n+s2, wheren is the number of possible states. The result value

is the reduced state (a single bit) for that fragment server; therefore, with eight states, the result LUT is 64 bytes, where 64 states would require 32,768 bytes. To add randomness, if there are three obfuscated states per state, the result index becomes s0×3n2+s1×3n+s2.2