 Hi, I'm Paul Bunn and I'm here to talk about joint work with Ayal Koushya-Levitz and Raphael Ostrovsky, CNF, FSS, and its applications. Outline for the talk, I'll give a little background, talk about the two main results in our paper, and conclude with a summary. So starting with the background, let's start with FSS, which is short for Function Secret Sharing. It was created by Gilboa and Asshai in 2015 and followed up in several works over the next couple years. So Function Secret Sharing is an analog of Standard Secret Sharing. In Standard Secret Sharing, a value is split between multiple parties with the property that any party by itself or any collection of unauthorized parties cannot recover the secret. But if a group of authorized parties, in this case it would be both servers, get together, they can combine their information to recover the secret. So Function Secret Sharing is a similar idea, except instead of a single value, you now have a function that you are splitting between two or more parties. So Function Secret Sharing has three main algorithms, a gen algorithm, which shares the secret shares of the function amongst the two or more parties, and eval algorithm, where parties are given an input to the function and using their key that they received as part of the gen protocol, they perform a computation on it. Then finally a reconstruct algorithm, which takes the shares that each party has generated and combines them to form the final function output. With the key property that the reconstructed value matches the underlying function that is being secret shared amongst the parties. Function Secret Sharing solutions exist only for certain classes of functions. The first class of functions that was studied were point functions, and the original works they showed how to create Function Secret Sharing, the three algorithms, and the solution was known as distributed point functions. And this class of functions can also be readily extended to step functions and intervals. The main parameters of interest for FSS is how many parties the solution works for, and how efficient the gen algorithm is in terms of how big the keys are that are dealt to each party. Typically the eval procedure is non-interactive, so each party is computing that locally. Then the reconstruction algorithm and the shares are combined usually in just a simple linear adding over whatever group the point function is over. The other component of CNF FSS is known as CNF key sharing, which was introduced by Ito et al in 87 and is also known as replication based secret sharing and multiple assignment secret sharing. And in this notion, instead of each party getting a single key, there are some access structures for which it is mandatory that each party actually gets multiple keys and depending on the groups that are able to reconstruct the secret. In our work, TP CNF sharing of FSS keys will mean that if S denotes a set of all subsets of size T of the indices between one and P, then we assign a unique key to every subset of size T. And for each index, party index I, TI will denote the set of subsets of size T that do not include the index I. Then we assign for each party I the keys associated to that subset. And it's easy to show that no T parties can reconstruct the secret and any group of T plus one parties can reconstruct the secret. In this talk, we're going to be focused on the cases of T equals two and P equals five then later for our second result for T equals one and P equals three. In general, CNF key sharing has been used in several applications in the past, including verifiable secret sharing and MPC protocols, fault tolerance and redundancies, PIR and other generalizations when we view CNF key sharing as a special case of formula-based secret sharing. Okay, moving to our first result of using CNF FSS to get more efficient multi-party FSS. So as some background, the one out of two DPF case was solved in the original FSS works. And solved here means optimal communication. So it can be demonstrated as a lower bound, you need at least log N bits of information in the key where N is the size of the DPF domain, the point function domain. So the original works constructed a gen protocol that realized that optimal log N communication. The case for P is more than two parties and the threshold is bigger than one has proven to be more elusive. So the original papers show square root N communication for the gen protocol. And later work improved this to the fourth root of N for certain parameters. For example, if P is a product of, if the number of players is a product of two smaller values, for example, P1 equals P2 equals 3 and the threshold is 2, then they showed how you could construct a threshold to nine parties FSS scheme with fourth root of N communication. So our main results for the first application is that for any parameters such that the number of parties is bigger than or equal to the threshold times some parameter D plus 1, then there is a TPFSS scheme that has communication roughly N to the 1 over 2D. And we demonstrate how to construct such a scheme. So as an example in the T equals 2 and P equals 5 case with D equals 2, this creates a threshold to five party FSS protocol with communication fourth root of N, which matches the previous result but for much smaller number of parties. In general, as the number of parties go up, the easier it is to construct such protocols. And I will note that the result on the previous slide was for nine parties in terms of a threshold to five party solution before our result, the best communication was quadratic. The second part of this result is that the resulting protocol can actually be made information theoretically secure, although we do lose a factor of two in the denominator of the exponent. So the communication is N to the 1 over D instead of 1 over 2D. So the intuition behind this result, so the way that the protocol is constructed, if you want to generate a DPF function on secret domain point X and value V, we chop the domain into a square, so root N by root N and write X equals i comma j. We also split the value into a product of two values. And then we use the original square root of N communication protocol to give a nine out of 10 keys. So there are 10 keys here and it has the property that if any nine of the keys are combined then nothing is learned and you need all 10 keys to reconstruct the secret function. Step two is to notice that 10 was deliberately chosen, which is five choose two, again the five and the two are going to come from the threshold and the number of parties. So let's let T denote all subsets of size two and we will enumerate these and associate keys to each subset. For key gen, we will deal to each party index i, all the keys for the group, the subsets T for which that party is not a part of, the index i is not a part of. Then eval, so we notice that because we split the domain as a square like this, the original dpf function, if you evaluate f on y, it's the same thing as taking the first function and evaluating it at y1. So if you break y up the same way we broke x up and write it coordinate wise in the square coordinates as y1 comma y2, then we apply the first function on y1 and the second function on y2. By the property of the individual dpfs on the right hand side here, f1 of y1 can be written as a sum of all 10 keys applied to y1 and f2 of y2 can be written as the sum of all 10 keys on y2. And so f of y is just the product of these two things. Now for correctness, we observe that if we expand out this product, every cross term will be involved a single dpf key for f1 and a single dpf key for f2. And because of the way the keys were distributed, any, so three out of the five parties will know the key for f1 and three out of the five will know the key for f2. And so by accounting argument, there will be at least one party that knows both keys and therefore will be able to compute this cross term. Meanwhile for security, note that this is a threshold two scheme, so no two parties should be able to reconstruct the secret. So if you have any two parties, say i and j, there will be one of these sets t, which is the set of all sets of size two, that contain both indices i and j, and therefore they won't be able to compute this cross term that involves this key. Then a quick computation of the cost. This is the fourth root of n. This was because we split the domain into root n by root n. And so applying the BGI 15 key gen procedure on that picks up another quadratic factor. And so in the end, you get n to the 1 fourth. So our second result will be focusing on the t equals one, p equals three case, and construct a one out of three CNF, FSS protocol. So as I mentioned before, the one out of two case was totally solved by the original papers. They achieved the optimal logarithmic communication in n for a key gen. And we observed that this also implies this can be trivially extended to more parties with the same threshold. So you could also get a one out of three protocol with log n communication. Meanwhile, two out of three, the situation is a little bit worse. So in the original works, as well as MBKK020, they showed how to construct the root n solution achieves two out of three. And so we noticed the gap, a lower bound, which is still the theoretic lower bound of log n and an upper bound now of square root n. And just taking a step back and thinking about one out of three CNF, FSS actually means, so because it's a CNF sharing between three parties, that means there's going to be three keys total. And by the rules of how the keys are distributed, each party receives two of these three keys. And if you compare this to what two out of three FSS means, again, there is three keys, this time one for each party. And because it's two out of three secure, that means that if any two parties get together and combine their keys, then nothing is revealed. So in both cases, each party is receiving two of the three keys. And so one out of three CNF, FSS can sort of be thought as lying somewhere between pure one out of three FSS and two out of three FSS. And certainly two out of three, if you have a two out of three FSS scheme, you can trivially construct a one out of three CNF, FSS scheme, simply by dealing an extra key to each party. And I'll observe that in some settings, where two out of three FSS might naturally be used, you can actually use one out of three CNF, FSS instead. And this works in settings where each party needs to perform the role of not only its own computation, but one other party's computation. And this naturally occurs in various settings, including DoRAM. So the question is, what can we achieve for the GEN protocol in terms of communication for one out of three CNF, FSS, as a closer to the log N lower bound or to the best known upper bound of square root N? So our result is that there exists a one out of three CNF, DPF scheme with communication log squared N, which is close to the optimal lower bound. And we actually construct such an algorithm, which I will present the intuition for now. So for the intuition, let's go back to how the two bounds are constructed. So for the one out of two case of log N, we imagine a binary tree for the size of the domain. So this tree has that log N. And we're going to traverse this tree and create keys for each level of the tree or values, which are actually primarily PRG seeds. So this is where the log N size is coming from. And the key is, as we traverse this tree as part of PGEN, we want to maintain an invariant. And the invariant is that if you are on the path that specifies the secret DPF location, then you have two values, one for each of the two parties. And these are PRG seeds, and they are not equal. But as soon as you go off the path, the seeds will be equal for the two parties. And so the key is, as you're traversing this tree, and if you have maintained this invariant up to this point, you need to maintain the invariant so that as you go to the proper child, the invariant is maintained. And as you switch to the new off path child, you get the opposite property where the keys now match. And of course, in all other places, that's already off path, you need to preserve the invariant that the PRG seeds match for the two parties. For the two out of three case, recall that the GEN protocol, the best known algorithms achieve square root N. So they take the domain and break it up into root N blocks, all of size root N. And again, they deal PRG seeds to the different parties. And the way the PRG seeds are chosen is that in the off-block positions, every party, each party's two seeds will overlap with exactly one of the other party's seeds. So you can see B here is replicated, C is replicated between parties two and three, and A is replicated between parties one and three. Meanwhile, for the secret location, which is this block here, every party has the same. There's one seed that's common to all three parties, and each party's other seed is distinct. Nobody else has it. And the observation for the intuition for why this is two out of three secures, in both cases you can't tell if you're in the case where each seed is duplicated twice or whether there's a single distinct seed. From any two-player's perspective, one of their seeds overlaps and the other one doesn't. And that's the key invariant here, where for the on-path block, the keys overlap this way, and for the off-blocks they overlap in a different way. So the intuition for how the one out of three CNF scheme is going to work is we're going to combine these two approaches, where we have the binary tree structure of the one out of two solution, but the invariant that we're going to maintain as we traverse this tree looks more like the invariant for the two out of three case. So here now you have each party has three seeds and the invariant that you will maintain is that in the, if you're on the path of the secret location, there are total four seeds, A, B, C, and D, and each party has D, and then two of the three of the other. So this one has A and B, it's missing C, this one has B and C, it's missing A, and so forth. Meanwhile, on the off-path cases, every part there's three distinct seeds instead of four, and each party has all three of them. Now, of course, this is no longer two out of three secure, because if any two parties compare their seeds, they'll see when they're off-path, three seeds exactly match, and if they're on path, two of their three seeds will match. Okay, so as a summary, so in summary, we define the notion of CNF-FSS and show two results that demonstrated its utility. So first, we demonstrated how the generic notion of CNF-FSS could be used to take existing CNF-FSS schemes for many players and recombine the keys in such a way that we get more efficient standard T out of P-FSS for fewer parties. Our second result was constructing a one out of three CNF-FSS scheme directly with near optimal communication, and in particular vastly superior to the two out of three FSS case. There are various applications of CNF-FSS. As our two results show, we have more efficient standard T out of P-FSS protocols. For the one out of three case, we showed how this can be used to speed up various DoRAM protocols, and in general, we pick up the CNF-FSS enjoys the same sort of application advantages that other CNF key sharing schemes have. So as open problems, can you use either CNF-FSS or some other mechanism to improve upon two out of three case, which currently best known is root N? Anything less than root N would be interesting. Our first results showed how to do two out of five in less than root N, namely N to the one-fourth communication. Can we shave this down even further for three players? And in general, our first result also works for certain parameter choices of T and B. Two and five was a convenient application, but thinking back on the restriction that P has to be at least T times some parameter D plus one. So this works well in certain parameter regimes for T and P, but in general, can we solve T out of P-FSS in less communication? Enclose the theoretical gap of log N communication versus best known. And finally, can we find other applications of CNF-FSS where we can utilize the overlapping key structure to do things and improve on other protocols? Thank you.