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.  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 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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.  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.


How's everybody doing? Happy a good afternoon Was was lunch good you made it back You may have just in time. So the regular announcements, of course Jeopardy tonight Wi-Fi is probably still up at least it was up half an hour ago And there's still lockpicking going on outside in the tents if you want to have a conversation feel free to scoot out into the garden and Remain in here because This is a special occasion Arvind is here for his first talk at a conference for all of you So He does apps application security at doc you sign right he started out in development But moved into the security space after getting a graduate degree So he's got a motivation for some developer friendly things in security And basically taking ways of taking security processes integrating them into the development processes and so right in line with that He's going to present for you static code analysis should be for developers not for you. Thanks Arvind Thank you everyone from coming in it's right up to lunch. I'm pretty sure everybody is super attentive and Thank you to account for giving me this opportunity. This is my first talk in a conference So yeah, I'm excited So today I'll be presenting on something. I'm really passionate about and I've been working on this for past year making security developer friendly as a whole team but in this one mainly making static code analysis work for developers If you don't know what's a static code analysis It's pretty simple you have your code in version control and you use a bunch of tools to scan it to find some obvious box That's somebody might developer might have missed before we go forward a simple warning that all the opinions expressed and the tools I call out are my opinions and Not of docusign in any way About me I go by RV. So it's easy to call and also my Currently I'm an app second junior at docusign. I've been an app second junior at Nike and I was before that I was a software engineer at VMware. I have a master's degree from computer science in computer science at from ASU a special thanks to John Heisman and Skyler Berg who also worked on this project and their Guidance and work has been incredible without that. This could not have been done So today's agenda is pretty simple I'll go through what's what I think is the problem with current static code analysis tools and what was our solution? What did we build and What did I learn in the process and some of the features that I think are important and finally? I'll end with some unsolicited advice as usual, which is more of a call to action, but anyway So problem statement. I'm a I'm a fan of metaphors. So I it's easy to grasp the problem through a metaphor So let's do one That's one and if you're not familiar with it, which I assume most of the room is This is from Hindu mythology Ramayana and the situation is one of the protagonist is hurt in an epic battle and the healer on the ground says Hey, we can fix him But we need a specific medicinal plant called Sanjeevani, which only grows in Himalayas and Since it's far they asked the monkey god Hanuman to bring it Hanuman goes to Himalayas finds the mountain but cannot identify the specific medicinal plant so instead of bringing that he brings whole mountain and Keeps it on the ground so that the healers can find it and Heal the protagonist this is kind of what this static analysis tool does we need specific fix Problems to fix our code base instead of that it brings whole mountain and just keeps it before us The expectation it has is someone in some of the security person knows what to focus on and what to ignore But more often than not it's gonna be a developer who's gonna be looking at it And they have their own mountain to climb and if you keep one more, it's just an obstacle They're gonna avoid to put into words The problem problems are they're monolithic tools trying to scan Every language and every framework that's available. So it's it's gonna be generic It's a huge task to be honest and also it's built for security professional in the sense they have so much information and You know held for security professional with the CVC vs. All things are great But a developer needs to know how to fix it and why not fixing it as a problem That's all they need to know and since they're casting a wide net to catch everything possible in every place It's there are a lot of things that are not bugs. They are mostly You know false positives and if you keep getting in the habit of saying oh ignore that it's a false positive They're gonna come to you three times later. They start ignoring without asking you and It's it's great works great as a silo as its own animal. You can scan whenever it's comfortable for you. It's quick It's it's works great for you, but it's not integrated with the existing engineering, you know systems Some vendors are really trying to get there and they give option, but that's not its primary purpose So it's it seems kind of janky if you try to do that to make my case I borrowed a slide from our friend my friend Clean Gibbler who recently presented in shell con about rolling your own sass tool And he makes an interesting case that when should you buy a sass tool and his observations are Let's say if you have modern frameworks Or if you have if you want to ship it quickly through CI city platform Or if you have invested time in building some safe libraries like we did which are highly recommend Then it might not be for you buying one might not give the best results And also he makes an interesting case that even if you buy an off-the-shelf tool You might end up writing a lot of automation code to work with your system and make it You know it's in black box that you don't know what's happening inside You have to write something else to make it work for you So inevitably like it's not more of an option It's if you want to get some security value out of it We and you have you tend to write your own tool and that's what we did But we did not write another scanner another tool. We wrote a platform And because there are already so many scanners and you know, we have the code and also Grepp is amazing. So we don't have to keep writing new tools again and again. There's so many you know open source one we can use and So we can we used a plug-in model so you can plug in any tool within two to three hours with little coding and It's built for developers Whenever they need and what's the best effective method to give the feedback to them We use that we consult with them and it's not a one one time process. It's a in evolving process where you keep Making it better and better Improving something if something is not working out for you. So it's trained by our app sec team, which I have to thank I'll go through the life cycle of it. I'll go from both developer and app sec perspective it's important to think from developer perspective because if there's a less friction to use a tool or you want So you want them to use something the more adaptability it has if you if you rule with the Handfest and saying no you got to use this they might but they try to ignore you because it if it doesn't fit in your existing system So from a developer perspective everything starts at their source control and we start the process when a new PR is put up Because that's the best place to do it. I'll go into detail later But yeah, once it starts The request comes to CI CD pipeline and the CI CD pipeline Works for us because the teams CI CD team is our best ally instead of you know Going to every team and asking them to involve us or just adding it without telling anyone We we work with CI CD team to make it part of a pipeline. So anyone gets a new pipeline our tool comes with With it. So once CI CD sends a request from a developer perspective our tool our platform scans Scans the code and sends back the relevant result and one more thing we do do it here is we work with the team to To understand what works best for them. What how do they want to see this result? Not every team You know once in the same way if their system is different. They have their own process. So we work with them there as well We also create some security tickets to you know Follow it up or just to have a trail for it But the whole system is supposed to be seamless. So this these tickets are not for developers to look at and close and everything It's for us. Let's say if they fix the Any problem we found in for in next commit then this ticket is automatically closed if not tickets remains and one of our App sec engineers will go in and they open a bug so that they can come back and fix it So trying to do as much as booking bookkeeping for them and just helping them to fix the bug is one of the key for success And from our perspective when our when we get up when we get the request from CI CD pipeline we do multiple things but one of the main things we do is Cloning the cloning the code in our local storage and mounting it to our containers This is the scan important and we scan the files that the PR is touching This is important because I have seen tools which work at the PR level when the PR is put up they again scan the whole You know whole application which I think is a squandered opportunity because you have you have Developers at the right moment when they're fixed working on some particular file So use that opportunity to fix, you know have them fix on that one and Then we'll send it to our containers and for most of you It's pretty obvious why we why we would you know container is all our tools we use multiple scanning tools to scan our code and It's a hard process if we have to keep installing it in every box We're gonna put our platform in it's a it's a lot of work and also Tools tend to behave differently based on what platform you're running it on what OS is it? So containerizing it made us easy And also it's important that we're not gonna use all the scanning tools all the all the tools we have on every PR Because it's not required we were Deciding which tools to use based on initially based on only on the language. Okay, we are scanning this language So we're gonna use these tools, but we realized well some repositories even though they have the same language They have different environment in the sense they might have some safe libraries or they You know, it's a internal one and we do not have to put some tools toolings in there So we added repository as one of the criteria then we realized even inside the repositories some folders and files Might need some additional tooling or some exceptions So we added that like the changes small changes like that make Can make your false positive rate come lower and lower and also Brings the experience better and better for For the developers if if you keep saying how this tool will generate some You know some bugs for you, but it doesn't apply to you just go ahead at some point It might so just making the system work for them is the best and Once everything is done all the details are all the findings are sent back to our platform here We do multiple things one of the important things we do is Filtering of it. So initially when we started what what I did was like if you're touching a file And if you find any finding in that file, we're gonna assign or we're gonna show it to you But we quickly got a pushback a fair foot pushback that hey I'm just changing some part of it code and other things. I'm not even sure I what it is So I'm not responsible for fixing it and also It's not a good practice to you know bunch all the unrelated changes in one PR So that's a fair pushback and we agreed with that who smelted Delta's not a good idea for in these situations and Of course, we write everything to date our database collect as much as data is possible Why did it was even if we currently don't have you know use cases for that at some point? We will and having this data is what lets you decide which tools are useful Which are not and to get some executive buy-in as well I'll go into detail on some of the features we have One of the important thing is giving giving feedback at the CI CD in the code review stage when they put up a PR The developers and engineers are open to you know reviews at that point. They are looking for feedback They want to fix it at that time. So it's better to give at that stage and also It's easier and much cheaper to fix at that stage if you run the tool whenever it's convenient for you and give them a Large amount of findings to fix fix it It's hard for them because they are working on something else the timing not fit and Touching some code is not ideal at that stage. So when they are fixing it That's the best place to give it to them and we have three ways of alerting one Blocking them. Let's say you find something in their PR and they have to fix it unless that their PR is blocked This is more of where we want to get to we for some rep for some teams we do it but For many we don't yet because either They're bigger team and they're faster and we are It needs a lot of mad power because you need an SLA You need a page of duty to do it and we need more resources to do that To this was a initial idea that I was really excited about that Hey, if you find anything we're gonna comment on that PR This seemed like a great idea and even work with smaller teams But it didn't work for bigger teams because they're already too many people reviewing and commenting and an automated tool Just common keep commenting on your PR Seems like a spam and people tend to ignore automated. You know these comments when real people are saying something there So what we ended up with most teams are alerting without blocking so we alert them saying that hey you failed our check But we don't block you yet. Please fix it and I honestly believe no developer wants to write shit code Like they are good people but they are constrained by different things So more than 50% of the time we have seen people fixing it or just at least asking us Hey, what is this about like how can I? Go about it But if they many some don't if they don't we have a trail of tickets where we can go back and open a bug So that it can be fixed later Now there is tool plug-in model This is important because we had a lot of tools we could use and also I strongly believe smaller tools with specific purposes are much more good at finding issues or classes of issues so that you can You can fix them Because we are okay with the fact that we might not catch everything But the things we catch are important and we are sure about it So smaller tools with specific purposes my jam and also there are many You know open source tools like devs came as my colleague talked about It's a no it's a plug-in built-first visual studio code So it's generic, but since it's open source you can change the You can change the rules it's scanning on and you can cut down the rules to bear minimum of what you want it to look for and Write your own custom rules so that you can scan on them Finding normalization. I mean this is specific to our case because it's you we are using multiple tools and getting multiple details from different kind of findings from different tools and Some tools are amazing at description and other things some tools are not I literally have a tool which the name of the finding was excess and Description was cross-site scripting. I mean I like the simplicity of it, but still Some more description a detailed one which can help developers would be useful Key reasons for success if I have to point out there are two of them one It's built for developers at every stage. We thought What would make you know developers life easy here and how can we help them and it's also? useful in the sense of Once you put it we tested with smaller teams got some buy-in and got their feedback of okay This is not working for us or this specific case doesn't work for us And we get we get ambiguous responses from different teams and it's expected because not everyone's the same and We should be okay with rolling rolling with that What works for them as much you work with them? It's better to better get their buy-in and building a great relationship with your developing team and also Accepting for what it is as static analysis tools are nothing but automation to catch low-hanging fruits They're not there to catch amazing bucks. They're not there to you know replace your pen testers If you put all the amazing buzzwords into it like machine learning you put you know artificial intelligence Blockchain for no reason like if you add all those things. Yeah, it might find some cool bugs But that's not the expectation and it's a lot of engineering work So the expectation is to find some of the You know mistakes that that are easy to make by developers that they might ignore and just Help them out and we should be doing that job. Well One more thing that worked for us is writing safe libraries and scanning for them and alerting people on that My my colleague talked about it if you have a more question on that, please talk to Morgan Roman there and this is not unique you know you Many many companies have already done that Because like I showed in the initial slide from Clint that the bar for writing your own or the necessity that comes It's really low. So you you tend to write your own all the bigger companies have done it talk to Google and You know Netflix a snapchat all of their have their own system because To get some security value out of the existing tools is hard These are some of the resources that I highly recommend rolling your own is Clint's presentation in shellcon and lessons lessons from building study analysis core is from wasp Apsic wasp in California last early this year my boss talked there. It's amazing and Oh, sorry, that's this one the lessons from building at at Google. That's a That's a paper that Google released which I learned amazing things from it's like a gold standard I at least in my mind and I learned a lot of things from there and the last tool like while our tool is We started it as a POC. So it's still not a open source tool. We're working on it It's highly embedded to our this thing our environment But one of the similar tools is Husky CI who steam I met in Defcon. They're amazing They're all the features I mentioned are not there But they are doing amazing work and they're pretty cool to talk to just check it out if you're interested in using one of these tools And so I said advice Well, I'm kind of ending it in an anti climactic, you know message here because as much as a lot building it And enjoyed the process and we are getting some value out of it I don't think it's the good way for whole industry to keep writing in every company We go to because it's it's not feasible. It's not scalable and huge waste of resource we should be working towards this goal and We are doing all this after I mean all the vendors have put a lot of work into it. They're smart people But I think they are focusing on wrong things And also trying to fit in the existing ecosystem of developers What's useful for them what we can how we can help them out fixing fitting in that context is very important And also we're also pretty good at finding bugs, you know, it's amazing like we love finding bugs It's fun, you know, you can we can just call out people. That's why we are in security anyway But like let's we have to you know build the process to fix them It's it's time for us to focus on and helping in enabling all the developers who are doing amazing things with empathy to fix it Because again, I strongly believe coming from a development background. I don't think developers want to write bad code They're just not have the resources and the support to do it And since I started with the mythological metaphor, it's only fair if I end with the some shit metaphor So this whole situation is like diapers You know diapers are for kids, but it's bought by their parents and The marketing is always towards, you know aimed towards parents So as an industry we have as an industry we we do the same thing It's used by developers the static analysis tools, but bought by security professionals as an industry We have done a great job of marketing it to us security professionals and making us Feel it's important, but now it's time to catch the shit kids made. So let's focus on that Thank you so much Anybody have any questions? Hey, great talk. Thank you. So I get that like Trying to do this QA process for catching bugs earlier on In the development process is good because You can you know get kind of earlier access the things that go wrong, but In environments that have a whole bunch of different development teams working adding code into the same code base How do you? How do you reconcile like maybe bug fixes that cause more bugs? And different situations like that or development teams that are from disparate Parts of the world and work differently together. How do you what's your advice for that? Yeah, I really think in doing whatever you can as much fancy tools you have The most important thing is to build a really solid relationship with the developers with the security team I do think and also In one of the slides I show can share I'll share it in LinkedIn later that We don't tell them like when when they go to see our the details of our finding We don't tell them that oh, this is this as CVS a score of this that this and everything we say specific things like what's the problem and how to fix it and For some of them. Yes, I agree like there are no Universal fixes and in those cases we always encourage like we have the link to directly contact us there I know it's a complex problem. I don't have a perfect answer for that But at least what has worked for us is a long-standing Relationship with developing teams where they can come to us at any time and we will Work with their situation rather than saying now. This is a bug. This is how you fix it This is this is the ultimate rule. So yeah, that has worked great for us Thank you. Thank you. So we're actually gonna shuffle outside for additional questions. So thank you very much, Arvind And thank you. Give a round of applause


Oh, we're going- Not enough, yeah. For sure. That whatever the answer is, it's not enough.  I guess like how does it work? Who controls it? Do you use toys? That's like right away what everybody asks me. I was going to say that. A lot of people just say how. And I don't even know how to answer that. But I feel like people might think that you're like scuba diving or something like a unicorn like cesspool and then mermaids are coming in. It's like not like that. It's just foreplay, basically. And then there are toys involved. Sometimes there are, sometimes there aren't. Right, so it's like foreplay to the extension. So the max extended. I guess that would be like the beginning for somebody else's. Oh my God, yeah, I get what you're saying. Yeah, okay. See like, I think about it because one of my favorite books ever is She Comes First. And it talks about foreplay for women being core play.  Right.  It doesn't. It doesn't. Mythbuster right here. Right, it doesn't. I feel like I interview a lot of my friends or actually when a lot of my friends like straight girls or straight guys, but mostly straight girls, when they are the ones that ask me questions, I think we talked about this before. When they ask me questions and I turn around and I ask them questions, the majority of the time they're like, oh yeah, I don't orgasm every time I have sex with guys. I'm like, oh my God, like that does not happen in a lesbian relationship. Like, whoa, like you can't just leave here without orgasming me at least a couple of times. Like what is wrong with you? I've heard for example, some women who are studs don't like to acknowledge their female parts at all. Right. They're really only about the strap on and they don't want any type of like stimulation. So in some relationships, do some lesbians become like non-orgasmic by choice? Yeah, in a way, like I have a lot of friends which would call Touch Me Nats, Touch Me Nats studs and like I think that it's a different mentality. They would feel like, you know, something happened in their lives to make them feel uncomfortable in that way to express themselves. So they kind of become closed off but they are kind of attached to maybe a strap.  Like if it's there, you know what I mean? But it does something for them mentally. Give me a little dictionary thing, right? Yeah, I got you. What are some terms that kind of describe sexuality that maybe the average person doesn't know? Okay, well first I'm a stim, right?  And then there's something in the middle that can kind of like straddle and I created stim. Yeah, then there's touch me not studs. And then there's like, someone might call me a femme and there's like pillow princess femme where you don't do anything, you just kind of like lay there and take everything. Take it all, yeah. That doesn't sound like terrible. Yeah. It's not like for a Sunday afternoon. Gold star lesbians and those are the ones that are virgins to men. For a lot of people they can't even imagine a world of sex that doesn't have to do in penetration.  It's how you define it because if you define like losing your virginity as penetration then yeah, I'm not a virgin, she is. But then to some people it's just having any kind of sexual contact that you can be grinding anything. That's considered sex to some people too, so. Yeah, if you have an orgasm, some people will consider having an orgasm as sex.  Yeah, it is. Like oh, that we need a man to de-virgin.  Right, that's a good point. That's messed up. That is. Yeah. I live in a world without that. I've never been with a man, are they virgins? Yeah. Well gold star, which actually sounds way more cool than virgins. Yeah. It's like you can't operate it. Gold star, yeah.  But how did you figure out that? Did you have to learn the hard way? I mean dental dams, for example, are things that we get passed out in sex ed classes that I don't know anybody who's really ever used. A what? What? Like a piece of foil wrap? It could be a piece of sheet, yeah. She had like a plastic wrap? What the heck? So no. No, I'm not involved in that. I mean, I guess, but for me, I'm very careful. Strap on. Yeah, we are careful. We put condoms on the strap on.  But other than that, I'm very like, I don't just mess around with people. Like, I have to get to know you and all that other things and then make sure that you are clean, we're clean. If we have to get tested, that's what it is. Have the people out there who know that they have a curiosity, but have that fear. What advice would you give? Just go for it, just try it. I feel like everybody is like sexually fluid in some way. That's what we're supposed to be like. We're not supposed to be held back by labels or anything like that. We're supposed to be able to express ourself and spread love and energy and whatever. And I believe in spirits and things like that. So if you connect with people, that's all that matters. You know what I mean? It's not really about the, oh my God, but it's a girl and I'm a girl. It's not really about that. It's really a connection. If you were to give advice out there to dudes on how to please a woman, what are some things that you're like, listen, you guys don't know the secret tip that you need to know. Oh my gosh. Okay, there's a clitoris and they love that. Okay, it's a big deal. I feel like I'm giving lessons all the time to my straight guy friends that can't figure out what is the problem. Go down a little bit more, actually a lot more. However many times that you might be going down in sex at this point, triple it up a little bit more. You know what I'm saying? At least triple it up, okay? And then if you're unsure, maybe check some pornos and get some techniques down with the tongue. You know what I mean? And then just keep it consistent. Like don't just be all over the place. You know what I mean? Like keep it consistent and that's what will get you the best results possible. As somebody who's been with both, what advice would you be able to give? And what do you think that both parties can learn from each other? The biggest difference is definitely the orgasm thing.  In the past when I have sex with men it would be sometimes. So I just think like Amber was saying, be consistent, learn your partner, learn every part of her, make sure that she is being satisfied at the end of the day just as much as you are. And then you said what can lesbians learn from? Yeah, from dudes. Oh. Okay, what I always- I do the aggression. Yeah, I always try to get her sometimes. The aggression.  But I think that it's not really about being straight or being gay. Like a lot of women with vaginas like penetration because that's, you know, what most vaginas like. Yeah, so don't be intimidated by it. You know, take it, figure out what works best for you and just like try to get into it as much as you can because when you're strapping a girl and you're not into it, obviously it's not as fun. And you guys definitely tied.  Thank you guys so much. Thank you. I've learned a lot in this lesson and I'm just gonna request an ending group hug. Yeah! If I start copping the feel, don't know. Don't hate on me now. Yay! I produced a fun video for Shameless Maya. Please go check it out. Also me and Amber have one more video where we shared a lot of secrets. Having a sexual dream involving someone here. I'm still ready. It's her and Kiera. Just, I'm sure everybody at home has also had the same dream. So. Oh!


Dear Miss Jacobs, it is with the deepest regret that I write to you today. Your son, Mickey, has been killed in action in the course of his duties under my command. The loss of a child is difficult for any parent, yet you should know that Agent Mickey Jacobs was one of the finest men I ever commanded. Mickey was dutiful and kind with an easy smile, a smile he professed on several occasions he got from you. The impact that his loss has had on us can only be a fraction of that which you must now be experiencing. His devotion to the principles of honor and self-sacrifice lived in every part of his life, and it was self-sacrifice of the highest order that led to his death. It has left to me then to provide my fullest devotion to the principle of honor, and it is that honor that demands for me a truthful retelling of events which led to his passing. First, in the interest of frankness, your son was not a security guard for a lumber company. Your son was a hero. On August 18th of this year, your son was stationed at one of our organization's facilities in South Alabama. A security breach occurred in one of our high-risk sectors, and your son was sent in as part of a team of individuals to stop the threat. Your son was at the front of a formation of seven agents when an automated door sealed him inside the facility without his team. With no support and spotty communication, your son made his way towards danger, providing fire support for the site's security staff on one of the lower levels. He was then tasked by the site director to rescue several of our research staff from the monsters that now roam the site. He was killed during the final rescue of these staff. Today, a dozen of our best minds are still alive because of your son. I cannot begin to understand the sorrow you must now feel, but know that your son's death was not in vain, and that he will be remembered by all those who knew him as a brave, dutiful, and honorable man. Sincerely, and most remorselessly yours, Agent Jonathan Bradley. Site 88's InfoSack AI has detected an attempt to disseminate classified materials. Intercepting, redirecting, and replacing with InfoSack-approved cover story. Agent Jonathan Bradley is to be reprimanded for this attempt. Dear Miss Jacobs encloses the remainder of Mickey Jacobs' severance pay. As you are listed as Mr. Jacobs' emergency contact, we trust you to remit this payment to him in our stead. It should be noted that despite Mr. Jacobs' recent problems with drug addiction and sudden disappearance, we will be willing to provide rehabilitation services at any time should he return. Thank you for your time. Signed, Chief of Security Jonathan Bradley, Southern Crosscut Pines.


Hi everyone, Joe for jaspeaskacebrakes.com coming at you with a quick little 2019-2020 Mosaic basketball hobby pack break, random team break number five from jaspeaskacebrakes.com A lot of things happening here, three different dice rolls here first We're going to give away five spots within the pack break Then we'll do the pack break itself And then we'll give away eight spots in this filler right here Where you have a chance to win the remaining teams in optic basketball three and four The rest of you will get chronicle spots right here Still some full spots available on jaspeaskacebrakes.com Let's grab this list first, first dice roll of three Give away the extra spots Good luck, roll it, randomize it Four to five, nine times One, two, three, four, five, six, seven, eight And ninth and final time After nine times, Kevin, Ryan Harold, Paul, David B and Ryan Harold Extra spots going your way So we'll put those little rooftops next to your name And now let's do the break itself What's a must-have out here, Carl, like food-wise? Sub-Logan, what's going on, man? Let's do names and teams three and a two five times One, two, three, four, and five There's Michael Hughes down to Paul, this is just for the break Different tab And three and a two, five times, four of the teams One, two, three, four, and five Pelicans down to jazz And no trade windows in these fillers here Here's the first half of the list right there There's the next half of the list right over here Let's sort by team and let's just print and rip Oh, and there's an RJ Barrett rookie card here, that's not too bad As well as the Tyler Hero MBA debut insert Which isn't too shabby either Tyler Hero goes to Stephen Kendrick And the RJ Barrett base rookie card goes to Chris Parent and the New York Knicks Alright, so let's flip the screens again here And now let's see who's going to win those filler spots The filler inside the filler So there's some dice, there's the list again And it's going to be the top eight after nine Five and a four, nine times, top eight after nine One, two, three, four, five, six, seven, eight And ninth and final time So after nine, the top eight So from nine on down, sad times But thanks for trying everybody In fact, we do have another opportunity If you want to try again If you firstly don't succeed, try try again Top eight happy times for you because you're in Ryan Harold with a spot that you won Michael, Carl, Carl, Carl, Patrick, Patrick, and James There you go Congrats to the top eight right there We'll see you in the next video for the next one JasperysCaseBricks.com