 Okay. Thank you guys. So I'll have to explain the title. So the paper is going to be about security of applications using hash functions. As you know that hash functions are used all over the place and many important applications. And in particular what we are going to ask is how to assess the best possible concrete security for each application so that we can correctly set security parameters and so on. And luckily we have a beautiful framework to answer this question which is a random oracle methodology. Namely we will assume that our hash functions model is an ideal function from some domain to some range and because our attacker probably will break the system and he can read the function all the inputs we will limit the number of queries to this ideal function by some parameter t. And now we are kind of in good shape. We have this really beautiful object. We have simple precise proofs. For example if you want to argue the security of collision resistance of hash function as a collision resistant hash function you very trivially get birthday bound. You again get like formal justifications that exhaustive search is the best way to break like one-way functions you know a very good one-way function so a good pseudo-random function pseudo-random generator etc. And we also develop a variety of really nice clean and intuitive techniques such that lazy sampling, programmability, the fact that the only way to tell the output of the random oracle from random you need to query it so you can extract this thing and so on. So this is nice and in fact we can kind of the purposes of this talk I'll formulate the random oracle heuristic as follows namely I'll formulate it in the terms of exact security namely that at least for natural application the security bound you get in this idealized you know maybe unrealistic random oracle model is actually equal to the best possible security in the standard model for the best possible instantiation of four and this methodology as far as you know is you know widely used in practice at least to give you an idea of the right setting of parameters. As serrations of course there were a bunch of really important influential papers that said that well this is a great methodology it might work for everything we care about but at least in theory there are some you know artificial examples where this methodology doesn't work so at least you have to be careful however you know even those papers are very important and taught us a lot about non-blockbox techniques and so on as far as I know doesn't affect security of any of the applications which are actually used in real life so it seems like they're kind of in good shape and you know this random oracle heuristic system kind of standing strong well I claim that there is actually an issue so maybe we should look at it a little bit more carefully so let's try to look at it zoom in let's actually try to look at you know explaining the titles and some of the cracks in the concrete more specifically cracks in the concrete security all right so let's look at some of the applications so this is random oracle mode this is standard model and just you know Jonathan cuts my closer he objected let's make sure we say that this is you know random oracle model is also standard model here I just don't have a different term standard model means just model without random oracle okay so that's what random oracle standard mode means so as I said well collision resistant hash functions birthday bound great well in the standard model we know that no single you know hash function could be collision resistant that's why we talk about families of collision resistant hash functions parameterized by some salt and so on in general for any particular guy you can actually hardware collision and just you know find collision and constant time for one way functions again we have this brute force search attack let's say length preserving one function t over n but there is this maybe a little bit less known but a beautiful old technique due to Helman who shows that a random even a random function can always be inverted by a circuit of you know sublinear in the domain size you know and to the to start size which is like actually a beautiful technique it led to you know it was you know optimized later it led to the invention of like rainbow tables which are extensively used in practice to find password tracking there are companies that use it so it's not like some hypothetical kind of thing this is actually something which is very relevant in use in real life and I'm glad that you know Jonathan taught me about random with tables I didn't know so if you want to know what they are this is you know what rainbow tables I if you want a more detailed descriptions you should look at his book with you that but yeah it's really cool thing if you haven't seen it and similar thing well somewhat different thing for example happens with the random generators again we have brute force search is ideal you know there is that's the only way to distinguish to the random generator from random however again maybe a little bit less well known indeed I saw quite a lot of people surprised but for example any particular increasing function has a heavy Fourier coefficient which kind of sound scary but in reality just you know translated it to actual attacks it means there is a particular parity of output bits which is a little bit biased how bias by you know one over square root of n so at least in theory it means that in constant time you can actually find you know in constant time you can distinguish the output let's say yes of random is advantage two to the minus 64 and if you see like for the last two examples if you actually plug in and to the two thirds here you're not getting one if you plug in one over here you're not getting one over square root of n right so we already start to see some kind of mismatches and of course if you look carefully and especially if you come from a practical side you're saying wait a second some of these attacks like hardwiring a collision you know finding heavy career coefficients I don't know what is very you know heavy Fourier coefficient for AS is so in particular you know the attack that they talked about our known uniform attacks alright so before you kind of storm out of the rubens okay he's cheating who cares about it let's actually look a little bit more carefully why it's actually relevant not just in theory but also in practice let me remind you about non-uniform adversaries so they're modeled as kind of families of circuits so this seems kind of you understand it's kind of nice yeah we should allow an attack like orbit or you know polynomial size circuit to break the scheme but what comes kind of implicit with this modeling is the fact that for every particular security parameter you can just hardwire for free you can change the circuit from security parameter to security parameter so you can kind of hardwire for free a lot of information such as collisions and so on this information in theory is called advice in practice it's called kind of preprocessing so in practice it kind of preprocessing could be viewed as a special case of this advice which actually can be kind of computed and hopefully at least somewhat feasibly for some setting of parameters so this kind of corresponds to a special case of potentially implementable attack and you can say well you know I don't really care about non-uniform attackers you know I don't know this for your coefficients so why do we care and there are important reasons both in theory and practice so one reason both in theory and practice important that uniform we can say okay what's the alternative let's not let's define it and we don't have very clean alternative so the only clean alternative I know which is super clean is uniform attackers but they arguably too weak because for any particular parameter we're not going to have like a security parameter going to infinity that eventually the attacker is not breaking the system in reality well ES has what I have 128 or you know 256 there is a particular security parameter and we are going to dedicate all specialized resources to do it so this is actually kind of maybe too unrealistic too because uniform attackers will not usually give you accurate estimate because the attacker can focus on this particular parameter and as I said as I talked about let's say rainbow table preprocessing is realistic at many settings like for password as I said there are companies that I built to do it and so on so it's not like a hypothetical thing so if you use passwords you definitely you know have to worry about things like rainbow tables for theory the most important reason I know is protocol composition so there was this kind of old debacle and zero knowledge where initially the knowledge was defined in a clean natural way against uniform kind of attacker simulators because then people saw that it's not even close to the sequential composition so we kind of had to change change uniform to new uniform suddenly sequential composition works and in general anytime you care about protocol composition at least in theory you know we seem you know non-uniform darker seems to be the way to go and there are some other reasons for example you know without losing reality we can assume that non-uniform attacker is deterministic but hardwiring the best randomness and there are some very nice in complexity theory hardness versus randomness trade-offs which crucially again work only in the uniform model so the point that I'm saying there are a lot of reasons both practical and theoretical why non-uniform attackers is a meaningful model of computation even though it allows this potentially unrealistic attackers so for now let's just try to see if we accept this model of computation or the model of attacks let's see let's just revisit our random model heuristic and suddenly based on the example that I gave you before we see that not only is it just false but it's like blatantly false for every application I know about in a complement as we saw from this table not just some artificial applications but you know pretty much every applications when either preprocessing allowed or if you are a practitioner or if you are a theoretician non-uniformity is allowed in either way so and of course the question is you know we would like to remedy the situation is can we salvage this methodology and be consistent with non-uniform adversaries for all the reasons I mentioned above and likely the answer is yes and that was you know formally done in a beautiful paper of Unruh it's a pity Dominic is not here but it's really cool paper if you haven't seen it some who seem to miss the mainstream of like a fiscation of all those kind of cool things but it's really a nice important paper and he introduces extension of the random oracle called random oracle with the zero input maybe it's not a sexy name so I'm looking feel free to help us maybe give a sexy name so that it becomes more mainstream but anyway so let's try to fix those cracks in the concrete so this is our traditional random oracle model the attacker can make key dynamic whereas during the attack so in the random oracle with the zero input we extend this model so we explicitly model the attacker is a two-stage attacker where in the first stage the attacker computes as bits of advice offline before breaking the system the attacker computes as bits of advice about the random oracle and then in the online phase in the online phase the attacker will actually try to break the system using this advice and now the attacker has only this oracle access to the system and this A0 is modeled as a this A0 is modeled as a computationally unbounded attacker who potentially gets but the important thing it gets the entire random oracle because random oracle exists it's just unfair to say the attacker when computing the advice doesn't have random oracle because that exists in this model and then passes like arbitrary as bits of advice possibly hard bit advice of oracle dependent advice to A1 and of course when the hash function is instantiated in practice this kind of becomes non-uniform advice in the standard model and you know you can ask why in the circuit there is only one parameter size of the circuit here separating S and T is just convenient for both practical and theoretical reasons for example you know if you want to actually more finely let's say talk about RAM attackers less space and time are kind of different anyway it's pretty clean not a big deal and in particular the random oracle and standard model separations disappear for example listen you want to find a collision on the random oracle just you know the preprocessing status becomes a function a really big function but still a concrete thing so just find collision and you know move forward you want to find heavy Fourier coefficient you know great it's still a concrete function you know when when A0 looks at it finds this heavy Fourier coefficient pass it along and so on and in fact I claim that we can even repair our random oracle methodology to state the following that the security in the random oracle with auxiliary input is actually equal to the security in the standard total again is non-uniform attackers for the best instantiation of the hash function and as far as I know hopefully this methodology is actually reasonable despite again theoretical counter examples but now if you talk about practical application this methodology is what we should use and you know in practical sense if you're a practitioner you don't care about non-uniform attackers as I said it immediately once you go prove security in this bound and implies security again is preprocessing attacks such as rainbow tables or conceivably new brilliant techniques not yet found okay we have this model seems kind of nice how do we handle it how do we deal with this random oracle with auxiliary input and here we immediately we try to prove it we have a problem so conditional this S bit we call it leakage or whatever advice about the random oracle potentially all values of the random oracle are not random and independent there are some bizarre correlations that actually we can compute shy I don't know what these correlations are they're like you know pretty hard to see for general functions you know here we allow even like random oracle functions and so on and you know if you look at this table we had all these beautiful techniques that we just have this led to these two line proofs and here everything disappears I mean lazy assembly well I cannot just you know because maybe that attacker leaks this value I cannot just make it inconsistent with leakage how do I see it's consistent with leakage it just becomes technically challenging even for the simplest tasks such as one wayness to the randomness and so on and so if you are kind of totally cool with leakage going out you know over our head we don't know what to do it's just everything kind of everything we knew breaks down right well luckily as I said Unruh has this beautiful paper so not everything breaks down so he introduces really cool technique called pre-sampling and the intuition is well because the leakage is bounded here the attacker can leak maybe a few values of the random oracle but he cannot not too many values are like heavily biased majority of values so we can pass to the advice if we can you know possibly using again possibly unbounded computation figure out which values are heavily biased and there are not that many we can pass it to the advice to A1 and the rest can be sample fresh and independent and lead to kind of a small error so this is kind of a formalization of this attack he said imagine the distinguisher who doesn't know so the distinguisher gets as bits of advice about to and then he can make key dynamic queries and in the real model this queries consistent with the random oracle so there will be no inconsistency with the leakage and in the ideal model I'm going to sample it completely so what Unruh showed is this is close epsilon close I'll tell you what epsilon is to the ideal model where I completely choose a completely new function except for a small set of like p where p is a parameter of pre-sampled points where the value of the function could be not random so in particular when you ask query x you either if it's in the pre-sample set you answer it's potentially non-random value y sub i and otherwise you have a completely fresh and independent random oracle r in the answer here but the leakage is still about all so the leakage is still about all so essentially the only thing consistent result could be the pre-sample set everything else is kind of random and independent and so this pre-sample set it can depend on potentially hard and you know very hard to compute way on the leakage about the random on the real leakage z about the random random and independent of z and of course the big question is how big is epsilon so that we can use this technique and essentially pretty remarkable that he have a general technique so he showed that epsilon that more the square root of sp over p in the general so let's see how to use it for example now I want to argue the security of one way function in this setting right so this is like my one way function so by Unruh I know that it's you know the situation of the pre-sample set essentially similar to the attacker inverting a random function module of this pre-sample points and here I can actually see that therefore the overall advantage is this Unruh's error epsilon plus the advantage again in this function it's very easy to see if I choose a random input with probability p over n it's going to be in pre-sample set so maybe I lost it's easy to invert it or whatever otherwise essentially I repeat my traditional analysis in the random oracle model essentially I need to balance out those two terms so I'll pick some whatever the best thing to do it and I get you know essentially the security like that and so you say wow great finally we can prove security but unfortunately it doesn't seem to make the generic attack so the best generic attack essentially we know at least for a wide setting of parameters you know above that you can improve it by Helmholtz technique is this is essentially a bound as T of n so we kind of lost a huge cubic root in security which is the best exact security so we have this bounds which up to cube root like not tight it's not good so this kind of motivates our thing is what is the best exact security for basic primitive which is as I said critical to instantiate this mythology in practice so let me state our result so first I'll tell you that we unfortunately disproved a really elegant conjecture of Unruh called pre-sampling conjecture but the practical implication for our kind of thesis is that for many functions on max pre-sampling even if you improve Unruh's bound maybe it's not tight cannot give you tight bounds so it's like essentially it's not powerful enough to get what we want eventually then we introduce new technique compression well it's at least new to this area and based on that we apply to get nearly tight bounds for variety of fundamental applications listed here and unfortunately this bounds so much weaker than traditional RAM not because you know we couldn't you know we couldn't prove better bounds as I said our bounds are nearly tight but because the new form attacker is indeed much more powerful as we saw there are those rainbow tables and so on so for this setting you say well it's great fine you can recover this bounds but they are so weak that you don't really care about practice we don't know this Fourier coefficients and so on so here we analyze an important technique used in practice how to defeat pre-processing in practice which is salting and here we actually look at the standard model because the attacker will not know about the salt you can actually get the security in the random model the standard input you know in the standard random model and this might be kind of a possible way to reconcile this gap between different in practice namely in situations where salt is kind of could be used essentially you know we get the best of both worlds and we can kind of party back again all right so I have a few minutes I'll leave the paper in more details so the first thing is about Unruh's pre-sampling it's limitation recall this is Unruh's bound so unfortunately if you see if you want to get negligible security you will have to set P to be super polynomial that's kind of not consistent with our traditional thing so Unruh conjecture that pre-sampling actually you know a better analysis could get us negligible epsilon even for polynomial pre-sampling set and we show that this is not the case namely maybe you can get rid of the square root but that's the best you can do and in the follow-up work so yeah so Unruh conjecture is false in this generality so in the follow-up work we actually show that this is tight you can actually improve Unruh by a square root factor but unfortunately not more but yeah in general this conjecture is false but you can say well maybe if you improve it by the square root maybe suddenly we start getting this case so if you look at the one-way function example let's see what we can do if we allow actually pre-sampling so this was like the old slide essentially one-half disappears here this one-third becomes one-half but we still get one-half and they still don't match so yes we improve security from your cube root to square root but it still doesn't match the exact attacks so in some sense this frowning phase still remains it's a little bit less frowning I'll tell you just in a couple of minutes is this compression paradigm where essentially we say that if the attacker has hypothetical attacker this non-uniform attacker has high advantage it must be he must be able to compress a random oracle which is impossible which leads to a contradiction so taking counter-positive because random oracle is impossible to compress we will derive exact security balance on how well the attacker can do and the challenge is that we have to compress the random oracle by more than sb because the attacker will refuse to run unless he gets the advice so the very first thing in this compression technique will be the sb of the advice that the attacker gets so we need to be pretty aggressive with our compression and decompression to get this result so let me tell you about the proof but just to give you an example of the kind of bounds we get for example if we talk about salted collision resistance and hash functions and I told you salt is kind of necessary because if we keep pre-processing otherwise you just hardware collisions we can get a bound of this form where k will be the universe of salt and this suddenly becomes tight because in space s you can hardware s collisions so essentially if we choose a random salt this probability s over k maybe the attacker just knows this collision and otherwise you have this standard birthday bound so let me skip the proof and just move on so it turns out there are some technical issues we need to solve very quickly talk about the rest of the results so we apply compression technique to a lot of fundamental primitives and we get concrete bounds so these bounds are always better than pre-sampling so if you just compare they always improve this pre-sampling thing so we do get some improvements and they're actually nearly tight so they nearly there are some small important gaps but they nearly match the existing attacks so now we can actually manage to get concrete bounds but of course as I tell you that considerative weaker than the best attacks in the standard model so maybe for practitioners like Tanya or then Bernstein they will say we don't really care we've been telling it to you all along so just don't use it well John is a peacemaker so he is liked by both theory and practice community so let's see if we can remedy the situation here and the answer is yes so the answer is salting so the idea in just kind of one minute we'll choose a random public salt after the pre-processing with the hope that the attacker didn't know the salt in advance so he doesn't know what salt to kind of attack so it's extensively used in theory and practice and indeed we show that all our bounds actually generalize to salt and very nicely you get this extra factor of salt over here so if you compare it with the traditional random oracle bounds you see in every case if you make salt long enough you suddenly start to match those things so actually random oracle bound becomes essentially the same as a bound in the standard model so if you actually do the calculation at most like log of capital and little n bits of salt they yield almost exactly the same security in the random oracle with the auxiliary input as without the auxiliary input so at least kind of informally salt like probably defeats pre-processing and now theory and practice can be happy you know can exist like it was done in this confidence alright so summary this is a short like one bullet summary change from t to s and t that allows us to fix those cracks in the concrete you know talking about the title of the previous paper if you know what I'm talking about so I claim that ray my eye is kind of the new cool kid in town is very clean just two parameters s and t it addresses both pre-processing and pre-processing well fortunately unfortunately depending on your point of view it becomes non-trivial there are elegant proof techniques but you know there are thousands of papers in the random oracle moment and essentially I claim that all of them need some kind of re-evaluation so if you want like a concise summary of the area it's kind of you can view it as obfuscation without the math not that there is anything wrong with math but you know it's clean you can practice you can like flex your muscles without like drowning and like branching programs and stuff like that so anyway so I'll stop here thanks Evgeny so we have maybe time for one short question before you have the opportunity also to switch tracks yes so since you need the salt to defeat the pre-processing you wouldn't be able to prove say like full domain hash as it stands because yeah because it's insecure so yeah full domain hash for example it's easy because if you can just hardwire a collision in the random oracle you will find two messages that collide you lost the signature of a one but so yeah so for that we will need salting we have some other picking some follow-up work about it but yeah in this particular case we cannot prove it because it's insecure but for us you know we have like for Schnorr we can prove actually security for example for Schnorr signature okay thank you