 Hello everyone, it's great to see so many people on our purely mathematical and cryptographical talk, so I try to Rule out as many formulas as possible, but so many of them are left here So this talk is of course intentionally Scientific to show up that we are doing something serious But there will be also like important numbers will be on the very last slides that like this slide before last So like number of constraints and this sort of stuff will be in the very end So if you are just coming just for that you can wait So this is a joint work of the company Simon waltz with every name and ABDK consulting and Also our colleagues from my universities of Bristol and Gratz are now Lorenzo, Christian, Sebastian and Marcus So this kind of work that was conducted a bit independently and then later merged and Still it's kind of work in progress. So we even haven't invented the proper name for the hash function so Okay, so You probably remember what the hash function is what property should have the good hash function should process arbitrary large input Well up to some extent, but pretty like that gigabytes should handle it should be collision resistant meaning that it should be difficult to Find x and y difference so that the hash of them are identical Well as long as hash function Converts arbitrary large inputs to fix size outputs collisions are unavoidable, but there must be difficult to find Pre-image resistant means that given why it must be difficult to find X so that hfx is why? Well hash functions in a theorem. I may think it has funds everywhere. Of course, mainly shot three so shot three or ketchup the hash function designed by Belgian Belgian team in Lead by a young diamond in about ten years ago. So shot three is built It's used to build a Patricia tree to construct the rest out of the public key and so on and so forth So if it's not like the best like in terms of opting not the fastest hash function in the world But it still can handle up to like 500 Bates per meg bytes per second Well to understand why we need a different hash function. I'll go a bit to the introduction how hash functions are used in Snarks, so this is some sort of repetition a bit of the previous stark talk. Well in Bitcoin we signed because usually I start have to start with Bitcoin unfortunately because They have zero knowledge proofs apply usually to a transaction output You take so based systems So we sign a transaction with some output and the hash function of transaction is included in the block and after some point we spent the output by by Signing the transaction and the output With the the private key that was in the hash and the crucial point here is that The hash of the transaction is referred in clear text When you want to introduce zero knowledge payment system This is concealed the hash of is concealed to break up the link between the original transaction to send and the transaction to spend So when the transaction is send It's not only included in the block but also added to especially crafted merkle 3t And when you want to spend it you prove that there is you know a transaction H which is in the merkle 3t that it has special structure and you know the private key that is That corresponds to the public key that is is in this transaction and here the transaction age is referred to in zero knowledge and The most computation expensive part in all protocols is to prove that the hash is part of the merkle tree So all the others Parts of the proof are rather fast. They all maybe even with previous in the original z-cash They can be managed within one second, but when you have like 29 or 32 layers in the merkle tree this becomes difficult to to prove because the Performance of zero knowledge proving protocols they scale linearly or even super linearly with the the number of invocations of the hash function and It turns out turned out very quickly that traditional hash function like regular hash function I'm not quite suited for snarks or starks or bulletproofs because there's circuits. They are optimized for Intel or AMD processors for modern architecture, but they are not optimized for For the environment where starks or snarks operate in these environments are big fields so The fields are either prime fields meaning that All now all kind of our state is a vector of integers model some prime number in this prime number is 256 bit or 384 bit depends how afraid you are of recent disk and logarithm complex estimates this for snarks and bulletproofs and For starks, they are most helpful Filled most Better best field to operate with us and stent is a binary field, but not that big So it's like to the 32 to the 64. That's like the easiest to construct read Solomon Proofs so We can say we can simplify and say that in snarks A trusted party just kind of applies a secret input to the circuit and We can say that like all intermediate states are hashed not to be true But still and all of them are published as a proven key and then bulletproofs starks this Secret input is not needed. So the proven key is just the circuit itself and for each proof they Took under to present a proof to create a proof You have to kind of match your execution your computation with the proven key So with the circuit or with the circuit on secret input So you have to like combine the two traces and That's why the bigger the circuit is that longer it takes to construct a proof and It depends on the circuit size It also depends on like if it's our algebraic trace like in snarks like a starts then and depends on the width of the On the size of the state you operate with on the degree if you permit arbitrary degree So different Parameters are invoked and the foremost might not be very simple, but there there's still some metric to to optimize And we know this metrics approximately for snarks. We know such metrics for bulletproofs and not such metrics for Starks So the question is the question that should have been Put when snarks and starks were designed So kind of weak cryptographic community bit missed this question This requirement that we there is a need in hash functions that operate in big prime fields or big binary fields That are best in certain metrics like circuit size or degree size products like in starks And they are of course secure because the first two are easy to construct. It's difficult to create a secure one and Fortunately our cryptographic and cryptanalytic experience allows us to create really fast hash functions because we know certain constructions that are reasonably that certainly fast and that we have Analyze them with cryptanalysis for years for decades And we know like the methods that could work the methods that usually do not work And we can quickly make a hash function that is secure and that Satisfies these requirements So one the first approach was MIMC about three years ago and the the idea of MIMC was pretty simple So in the core of the MIMC, there's a permutation So originally it appears as a cipher, but if you want hash function decide the key can be random number It's okay here. So The idea is very simple. So you have You add some constant Then you and you operate in a big field by default some Prime field and then you raise your result of the power of three in this field. So you square and then multiply again Then you add the constant then you then you put to the power raise to the power of three then add constant to the power three and so on and Each time the degree. So if you express actually it's easy to show that typical Cryptonetic attacks like the financial linear cut analysis don't work here because of algebraic structure and because the state is very wide but algebraic attacks work and the thing is we have to make our the degree of the polynomial that Corresponds to this to the output of the function You have to make that the polynomial is of high degree to prevent various sorts of attacks And the degree increases like degree multiplies by three each time and the maximum possible degree is Actually to the end when n is the width of the state and we have to execute like a Bit less than n steps to achieve maximum degree Well, actually actually a bit more but this is like the order so that you understand like if you if you if your permutation is I know 250 bits wide then you need Kind of at least 100 something steps to achieve maximum degree Okay, so there were also Peddersen hash Proposals, but we can directly go to our contributions because the others are not Exactly, so they're in different paradigm constructed and kind of not so interesting for us So our contributions consist of two parts. So the first part as more generic So it's about it's about Merkel trees and it turns out that we can do we can handle Merkel tree substantially better than before Recall well, this is like three layer Merkel trees Merkel tree that handles eight messages well suppose for simplicity that the hash function it takes like two We consider a compression function that compresses with their issue two to one and Every message is of the size of the hash function output and then in this case you need n layers to hash to the end messages Okay, and the thing is the very nice thing is you can do better because you can When you have form when you have two layers you can process more than four messages you can take fifth one and then jet carefully we absorb in several hash function outputs in three and Well, you have to and Using that you can for every like two layers you can Process not four messages, but five messages and that's give you well not so big But something like 20% in 15 20% increase In performance you should give and this works for every hash function and collision is pretty much resistance a bit decreases, but Collision resistance remains at the same point so generalized bird effect also doesn't seem to work and This construction works for any hash function Even more efficiently if we have a hash function that takes that can consume our bit very large input Well with the regular hash function. We already have that like we can we can feed Very big input to show free, but it will be yes a sort of Sequential invocation and here suppose that our hash function is tailored to where Large input size so the in the output size is small But what are the input size is big and we use this large width to achieve? Cryptographic security the thing is we can then decrease the number of layers of course So if for example you process the ratio is 4 to 1 that you need to twice fewer layers and What do we need? How can we do that? So what's the most optimal way of operation and It turns out that if we want to process some very wide input with a hash function Then a very secure and Construction is the framework. It's a cold sponge mode of operation and it's based on permutations Very wide permutation means permutation. I mean that It's transformation is an invertible transformation that applies to very wide block Here the blue the permutation is of width like 768 bits or more thousand bits two thousand bits four thousand bits we know how such permutations can be constructed and The idea how they operate is very simple So message is sort not onto the entire state but all the state But some so called capacity bits capacity is twice the security level here If you security level is 128 bit that capacity should be 256 and the message is sort so Sort then you call a permutation sort you called permutation sort called permutation then messages Consumed and then you output this with the same rate as you consume messages And of course permutation should be like ideal permutation the sense that It should this to some extent in the central from a random permutation. Well, it's a constant function But you should more or less understand what this means Okay, so the question is how to construct the permutation so that it will be start snark or stark friendly Okay, and the goal is to Come up with with the design that will be both stark and snark friendly to some extent because the difference We know that in snarks we optimize We work in the prime field in stark we optimize on We work in binary fields, but apart from that our permutation can be built very similarly the first attempt What if we modify my emcee and replace the power of three with an inversion and this is of course a very tempting step and It's not It's not actually Trivial so when the MMC wasn't was invented the authors tried this Approach and it doesn't work. That's work. Why because it's actually very interesting exercise that you can demonstrate that if that no matter how many rounds you have if you're doing just the constant addition between the inversions that The resultant function will be a rational function of the input of degree one The thing is you can Interpret your state as a fraction of like a little linear one linear offer another x plus b over six plus d And of course when you invert then the nominator and denominator that just swaps and when you add the constant the nominator changes, but the degree doesn't change and Unfortunately to the state will be a rational function of degree one and collisions are easy because they're like Simple linear equations or even quadratacons, but they can be solved easily so And there isn't design Jarvis. They decided to put some are additional linear transformations after the inversion But it's yet not unclear for me if this is secure enough, but they Haven't managed to break it yet The solution that is still obvious to me because I would like to work with white permutation because I would like to Leverage the permutation with to Get my more efficient circuit for a tree Not for one hash function for a tree Because that's the bottleneck and the idea that Why wouldn't we use multiple s boxes and to use a very wide permutation then our function will be very similar to what we already have for example in AES or other designs and Well, let's call it for example inversion hash and In this inversion hash it operates as follows. So It's you see like there are rounds and in this rounds We alternate non-linear transformations which are denoted by s. So each s is an inversion in some field It's not actually important for the design which field it is Because many attacks they apply Similarly, so of course you substitute as a parameter the field size and in some cases the binary For binary field some attacks work just a bit differently, but not tremendously differently So generally if your function is if this construction is secure for binary field, it will be like almost secure with the Prime field unless your primes or binary field is very small But the construction is like this. So each s is an inversion in the field and each a is a fine Isn't a fine transformation in this field. That's basically a linear combination of inputs invertible one it's and Another very nice idea is that for the middle of this construction. We do not need Full as box layer because the degree so the algebraic functions the algebraic attacks we work with they They can be kind of mitigated. They can be controlled even when with one as box in the middle or two but with one is fine and The parameters of this design are of course the width of an s box And I say that this is box can be prime field inversion for snarks Or this can be binary field inversion for starks and each by you can take whatever binary field you want So if you realize that if you think now that to to to binary field is good for Stark you can use it if later you realize that for like read Solomon performance you need 128 bit you can choose a bit different function if they will work fine and the analysis Analysis remains valid to most extent. So of course we conducted like mainly my colleagues conducted a number of different sorts of attacks on this design because we already know this design from like 20 years old just this s boxes were smaller and Apparently algebraic attacks become the most effective here but when you are 6 ourselves for example to 128 bit security you don't need many rounds here So we are talking about like six to eight rounds for outer rounds with full s boxes full box layers And I know five ten fifteen middle rounds So the total number of s boxes is not terribly big But it's interesting to optimize it. It's interesting to try to expand our permutation to see how big it should be to Give us the best circuits for trees and For stark setting what we have so In our inversion hash here the in the left column, there's width and We can calculate the formula pretty much the same formula the telebenza son is used has used for Approximating stark proof of performance and The result in performance Predictable performance is on the right most column and it's logarithm of time formula. So this should be read that if you shot a 56 For a tree of two to 32 elements then and you need 128 bit collision resistance then Your that proven time should be about two to the 33 of something If you spederson hash, then it should be like two to the 22 So you see like almost a thousand times faster, but of course Unfortunately in the real in the real world the before the performance increase from shot 56 is not that big because Shrattifice circuit is very sparse But still If we use our inversion hash, we can if we use like default width of 1000 bits We can still be like four times faster should be four times faster than Pedersen hash If we If we use And interestingly if we increase the width then we can do better and for 1500 bits and 200 2000 bits we can get best results. So 1536 is the best we can get it's like 60% faster than the smaller one so our current proposal is to use this with How many like not not very big number of rounds like eight Outer rounds and not that big number of internal rounds and the tree will be twice smaller For snarks, we can estimate the number of constraints, which is also interesting So suppose that we use 255 bit as boxes if you want to use snarks on elliptic curves with 255 bit primes if you want 3300 84 bit primes, then you should kind of yeah substitute them and it will be somewhat similar and so we can calculate the number of constraints and We can compare with Pedersen hash, which is like 40,000 constraints for the entire trees and if I Count it correctly and for this sort of hash for the entire tree if we use if we use six as boxes in parallel and You for 127 bit collision resistance, then we should have only 666 constraints well, maybe indeed for a fair comparison. We should use bigger prime But I think the order the order will be the same. So I think this is quite promising and Well, of course we advocate some additions to a VM or whatever will be used to Support natively support the operations in the field basically for verifiers because verifiers in starks and bulletproofs they need some parts of the circuit and some some field operations should be supported and Optional, I don't know if the entire permutation should be as a pre-compiled contract Maybe it's not necessary, but we will see they'll depending on whether some Checks against the entire permutation are Performed should be performed in the contract and if so then indeed a pre-compiled contract would help so This is just the beginning. It's just beginning That's kind of the hash function that we cryptographers can design within a short time period But I think there can be designed better better ones can be found. So we can try other start family fields we can Work better with algebraic attacks. For example, the grubbner-basis attacks are sort of and the finder explored and because And as far as they claim to be the best in the settings, it would be very interesting to apply existing grubbner-basis labor libraries to Attacks and see if they indeed kind of perform as we expect and It would be also cool to have some to fix some metrics and have some kind of competition That's like everyone can suggest a hash function that optimizes the number of constraints somewhere and which stands security attacks up to my note to the 128 Maybe design some merkle tree oriented hashing. There already exists tree based hashing, but maybe there can be something more optimal and Also, for example, maybe 120 bit security is not needed that much. Maybe if the hash function if the Proof should be like secure for only short period of time Then maybe a lower security level Would be nice for example 64 bit security level. I know maybe 56 bit security level That's like this then we have we can have much if again more compact designs and maybe with faster proofs and since fast certifications Thank you very much We have time for maybe one question so I'm sure you've heard about the New designs coming out for the Starks with Jarvis and Friday, although they're confined to the binary field How would you describe the relationship between your work and that? How what how would you describe the relationship between your work and that? How do you see them? I've just seen them two days ago and basically their idea is in the MIMC with only one registered to insert a fine layer and That's not yet clear for me if this indeed withstands algebraic Attacks because I have some doubts, but I haven't found an actual attack So maybe maybe it's indeed secure, but I would be very careful I think that the parts of use are needed Another round of applause, please