 Hello everyone, so this is a teaser to my talk Random Sources in Secure Computation. It's a joint work with Ady Rosena. So the model we look at is that of information theoretic secure computation, and parties have inputs x1 to xn, the adversary can corrupt at most t-parties, and the goal is computing some public function f without revealing anything more. We know that secure computation cannot be done without randomness. We need the ability to toss coins to securely compute a function, and a well-known natural equation is to understand how much randomness is needed to securely compute a function. It has been studied in many previous work, and the motivation for that is that producing high-quality cryptographic randomness is hard, it should be treated as a scarce resource. In this work we ask a related question which, to our knowledge, was never asked before. We ask how many parties need to have the ability to toss coins to be able to securely compute a function. The motivation is somewhat similar. In the real world, it's not always easy to produce high-quality randomness, because we might not have a proper device to do so. We might be using a phone that does not have a good way to produce high-quality randomness, or maybe we're using some code which was not correctly written and does not use the correct libraries to generate cryptographic quality randomness. So it might be that in Secure Computation protocol, we might want to avoid relying on the ability of some clients that use weaker devices to toss coins correctly. So for example, here, it would be possible to compute this five-party protocol without requiring the two holders of phones to use any random coins, relying only on the ability to generate randomness of these more trusted servers, trusted in the sense that they generate high-quality randomness. We have several results. The first result is a complete characterization of the random source complexity of T-private computation, a characterization of the number of parties who can toss random coins. So previous work showed that at least T-random sources are needed to securely compute a functionality with T-privacy. We show that T-plus-one parties are needed if you want to compute a randomized functionality and that T-plus-one parties are sufficient. And those turn out to be relatively easy results. It's quite natural if T-parties are corrupted, then you need to have at least one uncorrupted parties that then can toss random coins, hence the T-plus-one. But the most surprising result and the core result of our work is that actually if you only want to compute deterministic functionalities, which is still a very wide variety of functionalities, it is sufficient that T-parties have the ability to toss coins to T-privately compute all deterministic functionalities. And this is a quite surprising result because what this means is that even though secure computation is impossible deterministically, it becomes possible to securely compute all deterministic functionalities even in a setting where the adversary could potentially corrupt all parties that can toss random coins. And so in particular, the adversary could be able to see all coins ever tossed in the protocols. A second result that we study is a relation between the randomness complexity and the randomness complexity for some simple functionalities. More specifically, we look at the end functionality in the setting of one privacy, and we ask, is it possible to match the best known protocol that uses eight bits and two sources using the minimum number of sources, which by our previous result is a single source? And surprisingly, we managed to improve both the randomness complexity and the number of sources of this protocol and obtain a protocol that use only six random bits and a single source. So it's a result of independent interest for the randomness complexity of end, but also clarifies a bit the relation between randomness complexity and random source complexity. So for our first result, I'm giving here a high level summary of the protocol. So the key idea is that we will find a way to make sure that the sources never see anything private during the protocol, anything that depends on the private input so that when the adversary corrupts all the sources, then he cannot see anything non-trivial about the inputs. And if he corrupts someone else in the sources, then one of the sources has to be honest and we can exploit the fact that one of the sources is honest to guarantee that the parties can produce high quality randomness throughout the protocol. And for the second result, we maintain a very careful invariant throughout the protocol using only four random bits, and we transmit in a line this invariant throughout the parties, putting them in a line this way. And then we use two more random bits to complete the end of the protocol. We're using in very careful ways some of the bits that we used at the beginning of the protocol. I'm not giving more details for now, but I encourage you to come and see the online talk to hear more about that. And I'll be happy to see you soon. Goodbye.