 Hi there. Welcome to today's Protocol Labs Research Seminar. Today we are joined by Dr. Yevgeny Dodes, who is a fellow of the International Association for Cryptologic Research, or IACR, and a professor at New York University. Dr. Dodes has over 150 scientific publications at top venues and is the recipient of various awards, including the IACR Test of Time Award, which he's won twice for his work on fuzzy extractors and verifiable random functions. Today he will be talking about random number generation and extraction. So, Yevgeny, I will let you take it from here. Okay, thank you so much. Yeah, it's a pleasure to be here. Although my business is a long talk, and in fact we can choose these directions to go. We'll definitely finish on time, but if any topic is of particular interest, please ask me to go more in-depth. Okay, so for the way of introduction, some introductory slides, these pictures before we dive in into technical stuff. It's not a secret that randomness is needed everywhere. There are a lot of use cases here, approximation algorithms, distributed computing, and so on and so on. Of course, for this talk, I'm going to focus last but not least on cryptography. So what are the applications of, you know, why is randomness needed in cryptography? And again, the list is relatively obvious, but we'll go through it just for the sake of clarity. Most importantly, secret keys need to be random, otherwise they're not secret. So that's how we formalize secrecy from the attacker. For privacy, things like encryption, secret sharing, zero-knowledge, multi-party computation, we need randomness to randomize, I think, so that even if you repeat the same message, people don't see that it's the same message. You know, many kind of low-level usages for replay attacks, preventing replay attacks, adding random, you know, various applications of unpredictability, like short fingerprints and so on, anonymity, differential privacy, that's a common way to achieve this field called differential privacy is to add some kind of random noise to the otherwise correct answer. There are some efficiency applications, like, you know, best probability testing algorithms are probabilistic, and even I know less about it, but learning, even like blockchains and cryptocurrencies, obviously, they need like things like Byzantine Agreement, PCPs, snarks, you name it. So it's an important thing. So the other thing, of course, my last joke, and then we'll dive into hopefully serious topics, that randomness can lead to attacks. I'm listing very incomplete set of attacks, somewhat surprisingly, I was even involved in some attacks involved with better randomness. But the summary of all these attacks is it's not easy to attack RNG, but when the attacks are possible, the failures are really spectacular, like it covers the entire secret key, you can snoop on the conversation, you can listen everywhere. So it's not like, you know, sometimes people find some weaknesses that they can distinguish some beat or whatever, like a tiny little advantage, which is above the theoretical bound, here we're talking about complete breaks of the system. So we definitely want to get it right. So the question is, why do we get randomness for crypto in this case? So the answer is we use to the random number of generators. So this is a common design principle. So again, maybe it's a little bit of a joke. So from the perspective of the user, the random generator is like a button. So for those of you who are from the United States, we have the store called Staples here, and it's famous for the thread button, which says this is easy, and you kind of press the button, and everything just comes up to you. So here will be this random number generator, you press a button, you get a random number, you press it again, you get another random number and so on. And of course, it's kind of nice for the consumers who go to Staples, to buy super random number generators, but we're engineers, we need to design them, where does it come from? And what happens is this number generator needs an input, and that's why we call it Turingi with input. And the input is what we call entropy sources. It's something that we heuristically believe has some uncertainty to the attacker, it has some entropy, like mouse movements, keyboard timing, maybe temperature, but the most common one is really here. This is timing with interrupts. There are millions of interrupts happen since the computer, all of them come with this date stamp, you know, and it's like 32 bit number, sometimes 64 even. So it's believed that it has a lot of uncertainty to the attacker. Even if the attacker loops as interrupts, like this nano, micro, whatever, like seconds is completely infeasible to predict incorrectly, exactly those clock cycles. So this is the most common source of interrupts. We'll see why it's relevant later. And oh, sorry, was it something is okay. And the problem with this, even though they have enterprise, they're not uniform, not independent, not fresh, sometimes even other serial, maybe the attacker can, I don't know, pretend to type on a keyboard or, I don't know, run an intensive thing to hit the processor, whatever we want to even cause some interrupts. And to compare it with the state of art of other things, which is like other cryptographic primitives. So if you look at things like advanced encryption standard, Shastri, authenticated encryption, digital signature schemes, all of them started kind of at Hawke and crazy, but they matured over time. Almost all of them have some kind of standards by now. And you can argue that some things we can do better. But I would say basically by now, people just use any of the hash functions, they're not going to design their own hash functions, they will use Shastri or something like that. In contrast, if you look at the PRNG thing, there is a standard that listed here, but it's in a pretty primitive state. If you look the way this standard is written compared to this other standard, there is a lot of crazy at Hawke stuff. It's under specified, sometimes contradictory, there's a way of papers found this conflicts in it. It has some scandals for those who knows it was like this eCDBRG mode of operation, which was later believed to have a backdoor, maybe even intentionally planted by NSA because NSA recommended it. So just not mature, basically. So the hope of kind of my research over the last 20 years, I mean, maybe not, I'm being a little bit dramatic, but I kind of try to pull the state of the random number generators at least on par to make it somewhat comparable to this more mature fields of cryptography. And in fact, I will dare to go even further. As we will see, PRNG, it's basically a non, I mean, even though there is an interaction with prospective users, it's a very simple thing. There is no input, there is just an output. If you think about encryption, hash functions, there is an interaction with that, are like getting cyber tech signatures. If you think about it, at least from the perspective of the users, like a button, I didn't have to tell you like a security game or something. I just told you what the user expects. So in some optimistic universe, we can hope that we can understand it much better than some of those other things. And it can be like the most powerful of all. It will be like the foundations of maybe all cryptography, but maybe I'm dreaming, but at least this is a whole. Okay. So now that we talked a little bit about the lack of proper standardization and fundamental understanding. Well, what do people do in the real world? Like, there are all the separating systems, all of them need randomness, some who we still use encryption and so on. So what happens is they do a lot of, well, sometimes I hope, sometimes not, I'm going to talk about it. But the important thing to remember is that the good ones, the ones that you believe work, they use what you call cryptographic hash functions. I will come to it in more details. I usually have backup slides about it, but I decided to just basically summarize that the state of the file. Actually, I do have a few slides. Sorry. So let's keep some of them. But yeah, kind of going very briefly over it. So Linux DefRandom, it's like, it's complex. It has over 800 lines. Of course, it's very ad hoc and heuristic. One of my early papers since this year 2013, when we tried to look at it from a theoretical perspective was complete garbage. I mean, it was just, yeah, the attacks are not exploitable, they're theoretical attacks, but it doesn't accumulate the entropy. It's very easy to reverse engineer, see if the attacker is controlling the interrupts. So from a cryptographic point of view, it's garbage. But of course, in practice, it works. And in fact, if you fast forward nine years, it's not just me saying it for the sake of writing another paper. People in Linux, the field is maturing, they start to realize it. So in fact, this is the email that I got this January 15, I met Jason Donbilt, I think in real world trip, right before the pandemic in 2019, we started this conversation, I complained to him, he was in charge of like Linux RNG, or at least hoping to be in charge. So this is the email that he sent me, he said, hey, after meeting with you, finally I wrestled the control of Linux RNG, I can finally start working, he wrote a very long email, it was like three pages, I was like, oh my God, I have time to read it, it's exciting. With like very detailed thoughts, but he ended it with, I mean, you can read it, it says my goal with this RNG project is to have every component as rigorous as possible. So I think it's a fantastic jump from complete security by obscurity thing to trying to fix it. And in fact, this expert was from the emails and also there is like GitHub page about his thoughts about it. And I was a little bit humble, basically all the papers here referenced here when he was like looking for ideas to discuss things from me where my papers as a recent, you know, as like last year, he explicitly said, I had this paper, this kind of work, this doesn't work. And some of them will be used, you know, the final decision is not made, but they will be used basically in next iteration of Linux RNG. So for me, I have to admit, I love applied crypto, I love when my stuff gets used by training a mathematical cryptographer. And I found it completely fascinating that this work that I just did for the love of it, it was kind of fun, really has impact on such a major product. So we'll see how it goes. But yeah, definitely they're going to use at least some of our work, some of the words that I'm going to present here. So that was fun. Windows and Apple actually surprisingly were doing better from the beginning. Apple has a single year, Windows has something called Fortuna. And yeah, part of my work from the ones that eventually going to spend maybe half of the stock is going to be about proving that to some extent the enterprise accumulation seems to work in the way they design it, at least an abstraction of how they design it. They also have this thing which probably, unfortunately, I didn't have time to talk, but something cool that there was a lot of discussion about something called premature output calls, we call it premature next problem. Most likely I didn't have time to talk about it, there was heated discussion on this Linux, I think also CFRG mailing list that was involved in it, where whether this production again is a single premature next is needed was kind of decided probably it's not needed for Linux, but Windows and Apple anyway protect from it. So as a result, because it is used in Windows and Apple and you can debate with a such paranoid notion of security is important. We did analyze it in crypto 2014, we analyze some kind of idealized version of Fortuna and then a more closer to reality version of Fortuna, which is not as secure, unfortunately, my student is going to present it next week at information theory conference in Boston. So also last year at crypto and ITC conference also like something else called super past entry accumulation, which is used in this random number generators. And it will also be used to some extent in the new Linux RNG. So it was kind of really fun that a lot of work, some of it very recent analyzes practical ranges. So I would dare to say, even though those guys were predating some of my work, is I definitely got feedback I'm talking to both Windows and Apple designers, they took some of our proofs and cells of optimizations to tweak some of their parameters back. I mean, some of it I might mention if we have time. So I believe it had like a feedback loop backwards. Yeah, I started from analyzing those things, but then they actually took some of our, you know, minor optimizations and gestures and change, change the design a little bit. Okay, so I'm going to switch to PairNG theory. And as I said, you've seen a lot of papers, there'll be no way I can go. I mean, I'll just give you some kind of highlights and hopefully we get some understanding. We'll be happy to answer more questions offline and so on. Okay, so let's try to formalize this PairNG with input, except in the final papers, they formalize this, but I want to start with an easier problem where instead of producing many times, you repeatedly press a button, you just want to press a button once. And this is called a randomness extraction. So yeah, so what is this randomness extraction? So our goal here is to take those crazy enterprise sources and to convert it to a single bit string. And the hope is that this bit string is pseudo-random. So no distinguisher can tell this string that we output from a truly random string. So let's give it a name. The input is going to be x. The function is going to be x. The output is y. And our goal is to distinguish y from u. u will stand for uniform distribution, right? Of course, the big question is what assumptions about x you make. I mean, of course, that makes a whole difference. So the best assumption, so this notation means it's done something for me in entropy, but the details are not important for this talk. It's some notion of entropy, mathematical way to count how much entropy is there in this distribution. So it's not truly uniform, but it has this gamma bits of entropy. And our goal would be to say that as long as the input has entropy, the output is pseudo-random. Unfortunately, in this level of generality, this is impossible. So even if you want to extract one bit, it's kind of trivial to come up with artificial and realistic distribution, but the distribution would be uniform pre-image of zero, for example. I mean, one of the pre-images of zero and one will have a lot of strings. So let's say zero has more strings than one. So I just, I can even efficiently sample. I can pick random x until extractor x output zero, right? So this seems really contrived, but it does satisfy, it has very high entropy. So basically, it just shows that we need to do something to overcome this stupid counter example. So I had a detour, so I'm not going to go to this detour. So let me move to the kind of more practical part, which is, okay, so we have an impossibility of a general thing. How do we work around it? So how do we have impossibility results and work around it? So there are four of them. I will probably have time to barely cover the first two, but it's okay. It's kind of to get you the introduction and hopefully let you appetite to read more or to ask me to present again or something, but yeah. So all these workarounds, they're not fully disjoint, but the amazing thing about them, that's why I kind of love this area. This peer-in-git looks like a simple button, but because for various practical considerations, all of them played a role. All of them were helpful in some aspect of RNG design, whether it's super-past entropy accumulation or premature next or just extraction module itself. So that was a lot of fun. It will be to interrupt these questions, but yeah, this is kind of a high-level overview. So let's start with the seeding thing. I'll be a little bit kind of brief just to give you the highlight, because that was important, but there are now to be less important than the other ones. So the idea is to generalize the notion of extractor from the ones that take only, you know, deterministic functions that takes an input and output, the randomness. It also takes this random seed test, which sounds a little bit strange. We'll talk about it in a second, but for now just bear with me. The security says that even conditional on the seed, the output of the extractor is to the random up to some statistical error, let's say. And the canonical application, if you think about it, is like maybe key derivation. So you have this X, which is like secret randomness, and S is public randomness. Maybe it's published in advance or, you know, kind of some trusted source or single initialization vector or something like that for Shah. And the hope is that if X is kind of independent of this random seed S, you can get secret randomness from public randomness. So R is secret randomness, S is public randomness, so it's not completely chicken and egg problem. We are gaining something. We are gaining secrecy. So, and the key property, of course, of the quality of the extraction, aside from the actual efficiency of the extraction function, is the entropy loss. So the maximum we can extract is the entropy of S, but we're going to extract a little bit less. And the difference is called entropy loss. And ideally we would like the entropy loss to be very close to zero. Unfortunately, Radhakrishnan Tashma showed that any epsilon secure extractor, at least on this level of generality, should have entropy loss to the one of epsilon. If you want to extract from all high entropy sources, that's our goal. And there is something again, super famous lemma called the Tovar hash lemma, which says that something called universal hash function, if you don't know what it is, think about matrix vector multiplication, something very simple, achieve this entropy loss. So it looks like we are basically done, or at least in theory it looks like we are done. But the cons of this approach is that the CD sum is large, and the entropy loss, despite being optimal, is also large. So what do I mean by that? How bad is this to one of epsilon entropy loss? So many practical sources, they don't have this extra, you know, two time security parameter basically to waste. So like if you think about biometrics, I want to get like a key from my fingerprint or retina scan, like physical sources, even sometimes in low entropy environments. More important, you know, like if you think about Diffie-Hellman on elliptic curves, you get basically a random group of elements, you still need to hash it to get a string. And I understand you want to get maybe computational security, but even for computational security, you still need to have some information theoretic security to begin with. So for this thing, if I want to use some kind of leftover hash-based approach, basically translates to a larger, well, if my entropy loss is low, it gives me a smaller group size and it gives me high efficiency. So this is not about entropy deficient environment, it's just about the size of Diffie-Hellman group. So basically minimizing the entropy loss gives us much more efficient protocol because we can get the entire group element converted to a bit string as opposed to waste a bunch of bits. Like for example, in practice, if I want a yes-based application, this is traditional level of security that we kind of want for them, then entropy loss would be 256 bits, which is, you know, a little bit large for some cases. And the other thing, I don't have time, I had some backup slides for it, but if you have some kind of heuristic extractors using like random oracle model, we'll talk a little bit about something related, but not this. It's very trivial to see that they basically for free convert unpredictability to the randomness, kind of one-to-one exchange. So in practice, of course, people say, hey, they are okay with some kind of random oracle model or something, we'll rather use a smaller elliptic curve group. So people are just not going to use this stuff. So one of the questions that I asked in this series, so what will me and my co-authors and students, can you prove or improve the entropy loss for key derivation functions? And this is a job I should probably skip it. That's my claim to fame. That's the closest I got to a reference in the New Yorker magazine. So the paper was called, October Hashlemary Visited. And there was a reference in one of those first, this is actually one of the first popular press articles about cryptocurrency in October 10, 2011. A reporter from New Yorker came to crypto, like took a bunch of interviews. In the process, for whatever reason, my paper got mentioned. I think because this paper was starting the conference, and basically he said something like, oh, I saw this cryptographer as a serious people, but I look at these weird titles and understand it's a bunch of jokers or something like that. But listen, you don't choose your New Yorker reference. I'm happy I got reference. So anyway, famous paper winner. All right. So what is the point? Okay, so what's the point of this work? The question was, do we really need the statistical random or yes, if I get extracted with statistical random, I'm in good shape. But maybe it's kind of an overkill. And for some applications, no, for some applications, not an overkill. If you really want a one time pad encryption, yeah, there is not much you can do. It's not very hard to see. But what was surprising, the series of papers from like crypto TCC and to more crypto papers. For most of cryptographic applications, some surprisingly, we managed to beat the sort of Christian and Tashma bound in a provably secure way. And the key inside that there is a difference between extraction and key derivation. So if you know that you were deriving cryptographic for the application, you can use the quirks of that cryptographic application to do better. That was like really surprising to us. So unfortunately, I mean, it's like, you know, in Malta, basically, when I gave my summer school in Malta, I took another presentation and spoke for an hour and a half about it. Here, I'm just going to condense into one table just to give you a survey because this is like the least relevant to real Walter and Jesus. But we kind of like this work. So I want to tell you what we did. This was just not before work. That for any computation with secure application, you can use shot, you get a pillow, zero kind of for free. The assumption is like a numerical heuristic. And what is the minimal entropy that is kind of enough to derive an AS key, for example, 128 bits, one to one conversion, right? On the other hand, if you want to do it using leftover hash lemma, because of this entropy loss, there is no assumption, but you need 256 bits of enterprise. So how can we close the gap between 128 and 256? So first, it's like in this paper that reference in New York, we developed, you know, formalize something called square friendly applications. It includes a lot of things. It includes all signatures, for example, but it also includes semantically secure encryption, not like one time pad, which is not semantically secure. You can only use it once. But like if you use like, I don't know, any like CPE secure encryption, for example, you can use exactly the same leftover hash lemma that was the paper was called of tower hash lemma revisited, and you can have the entropy loss from two of them. So in concrete things, the size of the lippy curve could be smaller, for example, right? So you need like only 192 bits of enterprise. So if you want, you can say, you know what, I still want this 192, but I want to do it for everything. I want to even do it for some like super random functions, which are not covered here. So there are some applications which are not covered like super random functions and super random generators. If you want to go there like a small tweak to the construction, which yeah, I mean, I kind of details don't really matter, but something very practical, a very small tweak to this construction basically gives you the same thing from one way functions. So you kind of you need to use an additional computational assumption and it's the random generator and basically get the same result. That was like, we noticed it in a TCC paper next year. And finally, in the Eurocry paper, the following year, we did something really surprising. Follow-up predictability applications like digital signatures or master syndication codes. We basically the entropy loss is like tiny. Yeah, it's not zero, it's like log, log one of epsilon. And this is like a concrete number. So, you know, there is like plus four or something. So we get like very, very close to this. So anyway, so this was like a summary of this work. So I'm ready to move on. Is there any questions? But yeah, I'm cramped literally like four papers at Eurocrypt into this one slide, but I hope it kind of makes sense to some extent. But you know, the reason I kind of wanted to go through it quickly and say, oh, wow, this is fantastic. Let's just apply it to PRNGs. And just to recall the reminders, PRNG takes some kind of maybe we'll have a seated PRNG, we have some seed, we have some internal state, we have some update based on like timing of interrupts, we get random bits, something like that. And answer is, you know, both yes and no. I'll give you two contradictory answers. On the other hand, in our original work, we did use seeded extractors. And in fact, this paper that I mentioned, that's also papers that attack Linux and formerly for the first time, we find this problem of antidepressant accumulation, which turned out to be very important for subsequent work. We did use seeded extractors kind of as a first approximation, but really kind of people didn't use like our suggestion when I came back to Linux and also Apple and say, hey, we have this amazing paper you can use Universal Hazard. I don't know, it's like, I don't know about that. And there were two problems, two reasons why they didn't do it. One reason is not real. The reason is like a more theoretical reason like, oh, chicken and I can eat randomness to extract randomness. But I mean, I think it's okay. I mean, you can probably trust like Apple to maybe know about something unless I want to completely screw, I had a paper about backdoors to the random generators, but kind of you can maybe trust like use digits of pi or something like that. I don't know. So maybe this is okay, because I see this is public, but the bigger problem is that in all this analysis, the source might be independent of the seed. And you know, if you publish it and all like operating systems or whatever, I mean, this is just too much. This is an realistic summary, we'll find out it's public. So in the long run, it's not a sustainable thing. And the attacks are really catastrophic. So if you know the seed, because everything is like information theoretic, some AX plus B, some simple linear algebra, basically the attacks are completely catastrophic. Well, in contrast, if you use cryptographic hash functions, yeah, there might be some theoretical attack, but they don't seem to be catastrophic. So in practice, nobody would ever use this. Yeah, so this is the point that I was making. So basically, this brings us to the second point. All right, let's see what people use in practice. And I told them practice people use this cryptographic hash functions. The nice thing about those things that they're seedless, we think they work in practice, and but the analysis is done in the idealized model, because you know, that's what cryptographic hash functions, it means. So let's go into this kind of thing. So let's start with this folklore result, which everybody kind of knows, and kind of understand about using random oracle as an extractor itself, right? This is like the result I told you about zero entropy loss and stuff. The model is very simple. So you have this source of the entropy gamma, and you will use geofax as your extracted randomness. And the point is if the attacker makes q queries bounded number of queries to the random oracle, the chance that the attacker is going to query it exactly on x is q times by union bound q times two to the minus gamma. So modularly, this is when geofax is random, because that's the only way the attacker can get information about geofax is by querying random oracle here. So you're kind of done, it looks like they are done. Unfortunately, this is not this is like bothered me for years until finally we wrote this paper, which I mean, I shouldn't say my work, but it took many years, I'm really happy about this work at Eurocrypt 2019. Yeah, but basically those are the two things that bother us before we fix this problem is from a theoretical standpoint, it's very unsatisfactory, random oracle is like an exponential seed, right? Because we are assuming effectively implicitly that x is independent, right? It's called oracle independent source. And we assume that x is independent from random oracle. So we effectively using exponential seed by in theory, we can even use like a very logarithmic seed. So it's just very unsatisfactory theoretically, but also in the practical things that's also unrealistic. For example, if you think about PNG that uses timing of interrupts, this PNG runs on the system, it itself causes interrupts. So clearly because the interrupts that causes would not be independent of the random oracles because they're caused by evaluation of G. So kind of there is this chicken and egg problem, so this assumption doesn't seem to be completely realistic for these practical sources. So I wasn't like really happy because the result is like too trivial, some quotes like, yes, a belief random oracle is a good extractor, but it just doesn't look like the right assumption about the sources. So it was kind of bothering me for a while until we found the solution. So and the solution was to define the problem in a more careful way and to formalize what we call oracle dependent sources. To say, listen, how, you know, I want to say that the source itself, it doesn't come just, you know, kind of on the bottom in a way independent of G, but it could be influenced by the random oracle. So abstractly, we have the attacker, he makes a bunch of queries to the random oracle, output x, and then the attacker gets a challenge, geofax or sticks, and the constrain is that in minentropy of access gamma. Of course, this doesn't really make sense, the way it's written, as the attacker knows x, obviously he can just query geofax directly. Right. So attacker has to forget something. I mean, it has to be, if the attacker is really outputting the source, it's unfair that the attacker should remember it. So we kind of more, we think the attacker is like really split into two parts like nature and the attacker. So he has to forget something. So we can say, you know what, he outputs x, but then he has to forget something, squeeze everything he knows into state sigma, and then has entropy based on this. Again, a moment reflection shows it doesn't work. For example, I can output, I don't, you know, I can, you know, call geof0 and call attacks and just output x and don't keep any state. Because random oracle is random, geof0 is random, right? So it just will satisfy this thing, but obviously not to the random mistake, it like totally everybody knows that it will be geof0. So normally I would have more slides until we arrive to the right conclusion. Let me tell you the right answer. So the right answer would be to condition not only on the state on the attacker, but also on the queries that the attacker makes here. So this way I'm saying, listen, the attacker has to forget something. And the entropy really has to come up internally from the attacker and not from the random oracle, that even if conditional queries, there is some extra randomness. So I'll comment a little bit why we believe this is a good modeling in practice also. But let's see what it buys us. Oh, yeah. So, you know, the intuition is exactly this thing that entropy has to come externally from inherent randomness of this sampler and not because a sampler, some could depend on the random oracle interaction, we're really trying to model like timing of interrupts, like uncertainty in measuring interrupts or like some thermal dynamics or some heat waves or whatever, like users moving the mouse, not because, oh, it's like my mouse movement is depending on shot two or something. So, yes, we can depend on random oracle interaction, but we need to give me more entropy. So I feel like it's a very reasonable way to model it, but now things become interesting. And the good news, and to me, it's a positive, it means that we did the right thing. We can prove the theorems that under this modeling, we get exactly the same bound as before. Q times 2 is a minus gamma. It's the same as a random oracle dependent bound, but now we include many, many more sources. In particular, we believe the solstice chicken and egg problem, we, you know, we can include sources that we care about like timing of interrupts. That could depend on the random oracle. And the proof, actually, it's like a few lines longer, but now it's kind of basically this condition exactly matches with the intuition that even conditional, this is gamma, every query is a distinguisher kind of, you know, yeah, none of these queries is actually likely to query it on X because effectively, they're kind of in this elegant modeling, we are prohibiting this high probability for the sampler to, I mean, this is a sampler of the distinguisher together for any of the queries to be on the input X. Yeah, you can output X, but you're basically not allowed to query directly. And this is like an elegant way to model it. So anyway, this is like a cute little kind of warm up. We also have an information theoretic version. So I felt like this is like a right way to do it to, you know, have a common generalization of standard extractors. Since the information theoretic version, you can have two queries while you sample X. But, you know, you have to satisfy this condition. After that, you get a challenge, but now you can make infinitely many queries. So after that, it's kind of too late, you can query the entire random oracle, but because you've already forgotten stuff, good luck, it's not going to help you intuitively. We call it our last thing, privacy is attacker makes bounded number of queries while sampling, which kind of means that the nature probably doesn't depend on too many, you know, evaluations of the random oracle like imperfections of measurement and so on. But yeah, the attacker, even if like years later you want to break it, you're fine. I mean, it's not going to help you. And we get actually a similar boundaries before, but there is an extra term and the next term for those of you who know, comes from this leftover hash lemma technique, which is so in some sense, even for this practical thing, we use tools from the series extractor literature. Remember, I told you, we are going to use some tools from city extractor literatures. So like the Torah hash lemma is kind of useful in this more practical bound. So the question now is, okay, great, we did this cute little result. It's like three lines, okay, instead of three line proofs, now you have like five line proof. Are we done with extraction? Why did they write a eurek paper? Is it just for the definition? Oh, actually it was a crypto paper, but never mind. The problem is, in the real world, we don't have this monolithic random oracles. So what we needed to build, we needed to build online extractors. And that's how real extractors actually works in operating systems, such as Apple and Windows. So more precisely, the problem of online extraction is that the source doesn't come at once. It comes into these blocks, like interrupt one, interrupt two, interrupt three, and all of these interrupts have a tiny amount of entropy individually. But together, they have a lot of entropy. But the extractor cannot remember all of them. The online extractor has to have a small state, and it has to accurately process them one at a time. And finally, when the user is ready, you press the button and you have this finalized function. So you have this refresh function that updates the state to accumulate entropy. And then you have a finalized function to, you have the finalized function to actually get the output. So, oh yeah, this is kind of in the pseudocode. And sorry, I'll put the pseudocode in a second, but the nice thing about it, only the syntax is fine trained. The security is the same. We still want to run the SOY, but the syntax is a little bit more constrained that basically you have to iteratively compute this refresh procedure, finally call finalized. And of course, in our things, everything will be some idealized model, like random oracle, ideal cypher, or something like that. So technically, all the algorithms have Oracle access to this ideal primitive, which is fine, including the attacker. So here is an example. So here is an example like CBC Mac. It's a very popular online extractor. So you have a like star with a fixed state and then you just absorb the input, apply random permutation or some kind of fixed key block cypher, and then you keep doing. So this is a refresh function. It just takes state, absorbs the input, applies permutation and keeps doing it. And this is a final output. So this is, and in fact, I had a trip to paper almost two decades ago, but 18 years ago, we proved that in the random permutation model in the Oracle independent setting, this is a good extractor. We even had some very good bounds and so on. So introduce some new technique. In fact, it's one of the suggestions in this standard. Remember, I told you this immature standard, one of the suggestions there. It's not enough. It was also used by Intel RNG. So this is a physical that has its own chip through random number generator. They still need a post processing function, the UCBC map, and they cite my paper here, why it's secure. But now that we have a new model and we can ask later a second, is this secure in the Oracle dependent setting? And someone surprised me when I asked the question, the answer was no. I mean, normally, I mean, I can ask you a question. It's a very cute attack. Would you guys be interested to see the attack or should I move on to the summary? Let me know if you're hoping to see the attack. It's cute. It's not. It's like two slides. What should I move forward with the summary? Any preference I'm monitoring in the chat? It could be a vote of one zero. I see, yes. All right. So let's see the attack. I think it's actually, I like even though it takes time from the summary, I would like to see the attack because I think it's, it kind of shows you that what we did and kind of explains it. So let's see the attack. All right. So let's try to remember what we are talking. So the attack in CBC. So the attacker can call around in permutation and then outputs a bunch of blocks x1, xl. Now, in case you can compute all of them in advance, you will see. And, you know, the attacker has internal randomness and it has to make sure that this internal randomness has entropy, even condition on its state and this thing and, you know, whatever. So it's clear. So here's what the attacker is going to do. Block number one, flip a random bit and says, okay, this probability one half will be zero to the end, this probability one half will be one to the end. And then the attacker forgets. He says, you know what, I myself will forget all this random bit, the attacker samples them, gives them to the challenger, but then forget them immediately. He says, yeah, you know, that's where the entropy will come in. So this coin, the attacker forgets, but what is the output here? Well, if you look at what the state from the perspective of the attacker forgot this coin, it's either pi of zero or pi of one. All right. So what is the next block? And this is a cool idea. I shouldn't say about my own work, but I'm sorry about it. But so this is the idea where you can see why the fact that the source can depend on the random permutation health. The second block will be either zero to the end or pi of zero plus XOR pi of one. So if you think about it, you kind of flip it. If this is pi of zero, it will be either pi of zero plus zero. So it's pi of zero or it will be pi of zero XOR or it will be pi of one because pi of zero cancels. Similarly, it's either pi of one or it will be pi of zero. But distribution wise, it's the same. Nothing changed. See, distribution wise, you edit this kind of random, you know, you edit one more bit of uncertainty, but the distribution is still with probability of one-half, it's pi of zero with probability of half pi of one. So this is a critical point. I want to make sure you guys get it. Right. And you see that I needed to evaluate random permutation to create this input. Otherwise, I wouldn't be able to know what pi of zero plus pi of one is. So you apply here. So it means that the state here is either pi square of zero, like pi of pi of zero, or pi square of one. You can guess what the attacker is going to do here. It's going to be with probability one-half. This guy with probability one-half is pi square of zero plus pi square of one. Again, because of this cancellation, distribution wise, nothing changed. And you can keep going. At the end of the day, you inject it like l bits of randomness, but the state only has one bit of entropy. So to finalize the attack, I don't care what finalize does. It could be the pantheos, shas three, whatever. I don't care. It has a deterministic function. So what the attacker will remember is just pi of zero of pi of one, those two things. And with this, it's completely clear that the attacker can distinguish the output from random, right? Because the output, anyway, has only at most one bit of entropy. But yeah, the attacker can just check, oh, is it finalize of pi of zero, finalize of pi of one? So clearly, it's not going to be secure. But basically, the point is after l steps, I claim I did accumulate l bits of entropy, because the attacker, I mean, it honestly forgot those bits, right? And this distribution is like basically independent of these bits. So basically, I, the attacker injected l bits, but only one bit of output was produced. And this is even conditional and everything. So I hope it kind of gives you some idea why our motion is not completely trivial, a very popular construction actually is not secure in all settings. So you have to be kind of careful about it. So yeah, so, you know, we spend time, but I like this counter example, hopefully explains in a concrete terms what our notion does. So now I can say, wait, wait a second, we have this insecure online extractors, do you actually have secure constructions? Unfortunately, yeah, some people ask me what is this HIPPO doing here? I don't know, I just wanted to do to explain what online means that you keep doing the same thing again. Anyway, the HIPPO came to life with this. There is a good question. I'll address, I'll address, well, I don't know if you already left, but I mean, I'll address it maybe in two minutes, just so that we can find a good, great question. So let's look at some other practical construction, perhaps even more popular than CBC Mac, but kind of similar popularities of Merkel-Demke construction. You just have a compression function, and you just iterate it, and you just output the final state. And we argued, so it was secure in the Oracle independent setting, but here fortunately we proved it secure with a much more complicated proof, but it is secure in our setting, so we are good. In fact, even information theoretic version could be secure, but here you need to truncate. It's not hard to see if you don't truncate, it's not secure information theoretically. I mean, not very hard to see because in some sense, yeah, I mean, if this has no, not hard to see, I will not tell you the reason why, but if you truncate a little bit by like two security parameter bits, which is reasonable for some of the longer hash functions, which are like 512 bits or something like that, even 256 is reasonable, it will be secure in the information theoretic sense. We also, everybody of course asked us like, who got craft check immediately said, what about HMAC, what about HMAC, because everybody's using HMAC, so we had a section on the paper, it was more painful than less because it has some weird things, it's like iPad, iPad, but good news, it's secure. Okay, so for people who use HMAC, HMAC was designed for different reasons, but luckily it wasn't screwed up enough, I mean, you could just use Merkel Denver, you don't need to do this bizarre stuff, but fortunately the bizarre stuff doesn't hurt you. Also, if you want to go a little bit inside SHA-2, so compression function of SHA-2 has this Davis-Meyers construction from the ideal cipher, you don't know the details, doesn't really matter just for the summary, but basically also securing the ideal cipher model. So in good shape, and finally for SHA-3, sponge construction, so sponge construction, you can think of generalization of CBC-MAC, so if C is equal to zero, this is CBC-MAC, which is insecure, but fortunately sponge does kind of have this absorbing part, and I forgot what that was as the name is, it does have this non-trivial separation on R&C, and as long as there is something which attacker cannot control the C's non-trivial, like it's more than like security parameter, they're good. I mean, so here technically, sorry, one important caveat, you cannot output the entire state, you will have to output like this part, because otherwise it's like reversible, right? So if you output the whole thing, you can go back, but if you output this thing, it's fine, right? So these are kind of our results. So the seeded variant was proven in a cool paper in Eurocript 16, but we proved the seedless variant. So I'm going to go to this slide, and then I will answer Yulin's question. So what about applications? Well, for one thing, it will be used as an upcoming Linux RNG, but it also already used, oh sorry, I was making a different point. I told you about online extractors, which is like one time problem, but what if you want to do it multiple times? And here you see I put like zero to the end to emphasize seedless. Fortunately, everything works. You know, every single give us a seedless PRNG. I mean, first just for completeness, maybe I should go a little bit faster, but anyway, the difference between PRNG and online extractor is that you extract many outputs, right? So you don't extract only one, you can press a button many times. And as a result, the finalist function needs to be generalized to what we call a next function. Rather than just outputting Y, it also has to say, hey, I'm not done yet. I still have a state to go. But with this abstraction, everything kind of, you know, you can define an adversarial model, it becomes more complex, that I can, you know, I will not go into it. But basically a natural generalization of online extractor will be this full notion of PRNG with input. It is more complex. But, you know, in particular, it must handle state compromise. If you compromise state at some point, and then you inject entropy, you should recover. This is a challenging thing to do, but we can do it. So Python is with some tweaks, I'm giving you as an example, for example. For the sponge tweak, previously we just output SR and go home. But now I have to tell you what's the next state is. And it turns out that Hutchinson, in a different context, it wasn't a seedless context, but he kind of came up with the right function. Yeah, we're still going to output this Y. But I'm going to, in order to produce the next state, I can't just take those two guys, because Y is kind of known to the attacker. I'm basically going to apply random permutation to both of them. This, unfortunately, also doesn't work because it's reversible. But if I add this fast forward XOR, kind of play with Davis Myers, everything works out. So basically the point is extraction result with some tweaks gave us a full PRNG results. So, okay, so I, well, I started a little bit late, but maybe I will take like five more minutes, maybe six minutes, if it's okay with you guys. So if you want a, so, so if it's okay, but yeah, please stop if you, if you'd rather wrap up now and take time for questions. Oh, yeah, I do want to address your last question. Maybe I'll just give you a little bit of advertisement for the other two parts of the talk. I actually believe it's open. So you want to ask the question, are these forgetful adversaries realistic? I believe absolutely because in fact, not only they're realistic, I believe that they're being super paranoid. I believe that I'm modeling something which is much, much more powerful than real world nature, which is a thing is a good designing cryptography to model something stronger than what you need. And basically why what I'm really trying to capture is randomness in the timing of interrupts. So what I'm saying is I said, listen, I'm not extracting like, Oh, because the interrupt depends on some call to show. I'm not extracting from the input alcohol to show what I'm extracting is there is some imprecisions like there is some clog jitter and you don't exactly know what, you know, this nanosecond or even like terasecond, whatever this is, this is what I'm extracting. Right. And from the perspective of the attacker, I model the attackers, both nature and the real attackers, a guy who's like trying to mess up with the interrupt and actually the nature that produces interrupt. So the real attacker doesn't control nature that much and say, okay, I can try to predict the interrupt, but probably forget something. So basically, my attacker is not just an attacker. There is like nature that attacker doesn't control. I'm basically allowing the attacker to control nature and then forget. This is much, much more powerful. But I think it's a good principle in cryptography. Do something which is more elegant, has a shorter definition and captures a larger class of attackers than what you want. So I feel, yeah, so there is, so if anything, I think the complaint that you know, my interpretation is a complaint would be the opposite. I'm losing entropy. Basically, I'm saying, yeah, you only count the entropy from the interrupts in reality. Maybe there is some hardness and shaz that you're not capturing. And I'm saying it's okay. I mean, hopefully, there is enough entropy nature to get a clean result. So it's true. Maybe I'm losing a little bit of entropy, but I'm okay with it. So this is my interpretation, but great question. So, yeah, they're kind of running out of time. I'll tell you a little bit just maybe like in two, three minutes, a preview of this thing, which I really like is it has some cute pictures. So I've done this at PNG. And it turns out there is a problem which is, no, we are not done, even though it's like a good piece of it. Practical PNG, the interrupts happen so frequently. There is no way you can evaluate shaft for every interrupt. It's just not going to happen, right? So here's the heuristic solutions that people use in the real world. Friendly interrupts, they do some kind of orders. They split refresh function into two parts. They don't call it like that. I call it like that, but there is a fast refresh function that is called to every interrupt. And this is super fast. No way you can call shaft one, just not enough time. And then you're slowly kind of when time is right, you kind of accumulate a lot of those calls you take. So this is X, you have the strategy start out and then you kind of periodically will call slow refresh, which will be a graphic hash function. And then you get the state test. And this is what they use to interrupt. So the user who needs randomness will kind of interrupt this output of the slow refresh. But in reality, basically, we need to split our refresh into two parts. And this part cannot be a cryptographic hash function. So this is a cool kind of part. So just to tell you a little bit of what is done in practice, I probably will not be able to cover our crypto paper last year and so on. But just to give you an idea of what people do in practice, in practice, fast entropy, so the slow one is just shot. And the fast entropy accumulation practice is rotating sort. So this is what people do. And the intuition is you have a bunch of this kind of registers, you do something super fast. And I hope if black tells you this amount of entropy, you hope in some heuristic ways that you can actually accumulate a lot of entropy together without calling a cryptographic hash function. So this is kind of the windows 10 RNG. It's very, very simple. It's actually uses rotation. So you take the current register R, you rotate cyclically rotated, and then you source the next timing of interval. So alpha rotation of R is a state register and X is the time of interval. And in particular, windows 10 grates by five. It has 32 bit register, it takes it, rotates it by five, and then source the next timing of interval. And intuitively, why rotate? Because all the entropy of timing of interrupts usually is a load of bits. So you want it kind of to propagate to more and more bits. This is kind of the philosophy of what these guys do. So let me just see. Yeah, so this is kind of the intuition. You have some entropy here, you have the guy here, you rotate it by five, it moves here, X has entropy here, you saw it, you have more entropy. So this is a kind of informal intuition with the question is kind of how to formalize it. Variation by five, well, variation to begin with y five and not six. Yes, six would be horrible, by the way. But you know, so yeah, so basically what we did, you know, and that was a challenge. This is the last thing I say, and I will kind of wrap up. Sorry, guys, yeah, I know I'm kind of going over time. So I'll wrap up after this slide. Basically, it's clear that we cannot have the same strong models that we had for store refresh. We cannot make the attacker too powerful. Because this rotating source is just even simpler than any algebra. It's such a simple function. So cryptographically, you're going to reverse engineer and break it. So we had to work hard to kind of cut some corners and make something reasonable, so that we can prove something. And anyway, we will tell you exactly how we did it. We kind of, you know, you wrote like a bunch of, you know, we had like these two papers, one at Crypto, one at ITC, formalizing and trying to understand the soundness of this super pass center of accumulation. There are super cute pictures, so you can read the paper as just was very applied work at the end. And the fun thing about it, I want to say, this is one thing that I want to say. It wasn't me, it was like super practical problem. But then we use techniques from Fourier analysis. So I like one of my favorite papers like Star Wars, like I don't know, Windows 10 or NG something super applied, formalize a problem, use techniques from Fourier analysis and cute mask convolutions and so on. And then went back to practice and do this like super funny pictures, kind of arguing that, yeah, Microsoft choice is good, but Apple's choice is even better. You know, Apple use rotation by seven, so it was kind of fun to do those practical things. We designed it with some better entry accumulation function instead of rotation, we use something else. Anyway, I'll, I'll read it up. They're not even close to them. There was another problem which I didn't talk about, but I'm going to move to the, to the summary slide. Sorry about it. It was kind of surprising, the fun area with a lot of questions, diverse connections. There are real world implications. It combined theory and practice in both directions. The point is that seedless energy extractors are important and hopefully it's time to move this problem to the 21st century. So anyway, this is, sorry again for going over time. No, this is great. Thank you so much.