zkStudyClub: Zero-Knowledge Proofs Security, in Practice [JP Aumasson, Taurus]

Transcript

all right hello everyone welcome back to uh this edition of zk study club today we're very happy and excited to welcome uh jp um amazon and he is the chief security officer at uh taurus he's going to be speaking us to us today about zero knowledge proof security and practice and you know specifically some of the lessons that he's he's learned or things that he's observed auditing several different projects in the zero knowledge space so jp it's a pleasure to have you um over to you thank you alex um well thank you for inviting me i'm very happy to be to be part of the club now um so i hope this this talk will be useful to you and to see in the ck community

uh some part of it might maybe be obvious to some of you or you may find that some part are wrong so i'd be happy to to hear your feedback your questions um and if you don't learn much from me maybe i will learn from you which is also a good thing so don't hesitate to interrupt me and actually so you just said that so now i'm gonna just start by interrupting you and i think the reason i wanna interrupt you is because some people may not be aware and i want to make sure everyone who views this later is aware of your background because you have a background in cryptography before doing this work and i think you know some people may know of some of the algorithms that you've worked on so you know just make sure you like can you briefly do some of

the prior work that you've done just for context yeah well my background is in the academy crypto symmetric crypto but the last five years or so i've done quite a few security assessments i don't want i don't like to use the word audit but i i looked into many components of blockchain technology bit wallets consensus protocols and morrison fee zika circuit zk pro systems uh but yeah i'm a cryptographer by training before crypto was cool before this blockchain business so i'm a bit more old-school than some of the folks so and i think if i'm not mistaken you worked on blake is that right yeah blake too and

maybe what people want to know crypto is always cool yeah so yeah so yeah guys don't hesitate to yeah ask your questions interrupt me as some familiar names and that is so very happy to have got here so i will talk about zika proof security in practice when practice i mean implementations so more specifically it would be about you know non-interactive ck arguments are supposed to interactive protocols that happen to be zika uh and i will focus more particularly on dk snarks so as you know they are one class of non-interactive zika arguments um

they're generally full succinct meaning that the proof is at constant size and very fiction time is essentially linear in the circuit size uh as alex mentioned in the introduction this is based on my experience of looking for bugs either on a let's say professional capacity being paid to other stuff or just for fun for my own interest so my experience is mostly with proof systems that use the graph 16 proof system as using indication ficon and many other projects and more recently i had a chance to to look into the technology of alio which uses marlin as part of their proof system but marlin is

just one of the components they also use graph16 but a lot of what i'm going to say applies to other proof systems or maybe plancksonic factor you know to some extent to starks as well so why i think it's a cool topic um why it's important i believe so first of all because from the perspective of blockchain projects it's a major risk so zika snacks in practice are relatively new are relatively complex so it's typically the recipe for non-trivial bugs for new classes of bugs and bugs that are hard to find and there's a lot at stake in terms of in terms of money in terms of tokens in terms of data and privacy

um so for example for zcash it's essential to ensure that the privacy of their users are protected and for the layout to protocols that use snarks for zika snacks and zika roll-ups it's also extremely important to to have some security assurance and maybe from my personal perspective i think that zk technologies are the most interactive interesting crypto by far today uh because it's uh well using practice first of all it's reward crypto as we say today uh it's deployed at scale there's a lot of interesting papers a lot of good card being written and it's intellectually interesting and

refreshing as a cryptographer that's been around for maybe 15 years you know i've used that i've looked at so many new ciphers new you know secure channel protocols uh new end-to-end encryption protocols and it's quite boring at the end it's always the same but differently so here it's a very new world that is relatively simple but complex at the same time so by simple i mean that it's not interactive so you just send one payload essentially um if you compare to mpc protocols that are highly interactive like threshold signing protocols where you have to to think and to reason in terms of asynchronous communication what

happened if this message is not received how do you secure a border protocol um i don't like returning in this context and the same for consciousness protocol to some extent but zk-snacks also complex understand that many moving parts many non-trivial components uh as part of the case large for example polynomial commitments and it's kind of multi-dimensional in terms of security because as the famous screen options sound as complete as zero knowledge and some notions that are more tied to the application so if you do not eat of a technology using zika snacks it's not only about the proof security it's about

is the proof securely used in the context of the of the application um so what does it mean to you know to think in terms of security of the case not in practice so i think generally the most critical notion is sound soundless the most likely to be compromised and also maybe the most critical in case is compromise so soundness is about making sure that proofs which are not valid are always rejected so you want to ensure that from the attack perspective it's impossible to forge a proof from scratch to alter a proof in the sense of malleability take a valid proof and turn it into another valid proof that would be

accepted and also to prevent the replay of proofs um so you may you may think of uh cases where different nullifiers were accepted as valid to replay a proof uh second zero knowledge so i know at this point maybe some of you might disagree when i said that zero knowledge is less important less critical and soundness um so happy to to hear counterpoints here uh but one reason when i where i rank the knowledge a second is um that there's little let's say it's a leeway looking information because you have a succinct proof uh so there's little freedom in leaking a lot of

information and even if on paper zkns is compromised in the sense that maybe some internal component is not as zika as it should be and maybe the proof is not valid in that sense but in practice exploiting that to leak information from the proof itself is not always trivial and not always feasible as far as i can tell and the last one completeness so in most of the cases it's more about well denier service availability usability in case for example valid proof is not accepted then the user is not happy and it might be exploited in indirect ways

and if you are systems like decentralized private competition dpc systems where arbitrary circuits are likely to be accepted if certain types of programs are not accepted then it would be a problem as well but presumably not as critical as uh compromise of soundness so at this point do you guys have any comments questions there is a comment in the chat uh yeah it uh just came in here yeah so uh well victor i can vocalize it uh i might as well just say i just like you're kind of you're asking if there's like if we disagreed and i guess i was

thinking like oh well what about like zkyc systems that people are proposing right now like i could imagine that you would actually care more about zero knowledge than in soundness in that case uh if you had to choose because uh people's personal identity is being protected by these kind of systems right yes yeah that's an example i would distinguish between the importance of um meeting the the privacy properties and the the actual like likelihood of them being broken because um i think you're right um jp that um in practice there's quite little scope for the proof itself to leak much information um

so yeah it's important to have a proof that it doesn't make information but if if privacy is gonna leak it's probably gonna leak from um other parts of the high-level protocol rather than from the sdk proofs right yeah and as you mentioned we should see it in terms of likelihood times impact uh where impact varies a lot depending on the on the application okay so now this part just briefly from my perspective as someone who likes finding bug and found a few uh maybe the problem for blockchain projects um when you want to hire people and you want to have an external view on

your project maybe you will agree that a common problem is that auditors have a limited experience because the kp's are relatively new limited knowledge because you you want people who understand both the theory to understand what what's happening and what's the risk and who understand the implementation and oftentimes you read the paper you look at the code and you're like okay what is that because implement implementers you know know a few optimizations a few tricks that are not mentioned in the paper so you need people who can you know understand the code and match the code to the to the specs and it's not always easy and unlike some other types

of protocols we don't have a checklist or there's no official no documented checklist of all the bugs that can happen all the things that can go wrong so as an auditor you build this base on your experience but i think depending on the team it's there's very few public resources online that will tell you oh that's the kind of bugs that you want to look for and likewise there's very little tooling and public methodology related to the gopro so and i think most of us will agree that most of the bugs most of the interesting bugs have been found not by external auditors but internally by internal audits or accidentally um if you took the case i think the

the bug that arya found in the cash in 2019 uh this book was very hard to catch for example um so i think this calls for a completely new approach from the auditor perspective um i think that what corpse is to have a highly collaborative approach with the designer so for example have regular video calls where you know the developers the guys who wrote the code walk you through the code and explain what's going on at the end score of the audience question and to have for example a chat channel where auditors can ask all the questions they have

uh if you if we think we found a bug so before writing is in the report and spending time ask the guys okay is it normal is my investment incorrect of what what can happen because oftentimes i would find something that makes me a bit nervous i'm like okay it shouldn't be this way but sometimes the developers told me no no that's you for reason we aware of it but look we can explain why it's always fine and also what i found very helpful was to do a threat analysis a kind of threat model where i have a clear view of what are the risks what input is controlled by the attacker what is what input depends on the context and what depends on the configuration so what are the degrees of

freedom um from the perspective of the attacker is ultimately you want to report useful bugs useful risk and the developers have to prioritize mitigation so you want to tell them whether this can be exploited or not um you don't want to pay them a list of things that as a cryptographer you don't like to see and also what i found extremely valuable is to try to you know play myself write some code uh played it with the code that i'm given to review um not try to call a complete throw from scratch but you know you learn only by doing you don't learn by reading code only so this practical experience is super important

and i've tried to find information about bugs about potential risks so of course in public disclosures what people document in write-ups what you may find in ctfs i also also looked at the reports by other teams i found very little useful information there to be honest but that's useful in itself and also looking into the issue trackers of different projects looking into the prs and it's not always clearly tag as a security issue sometimes you have to write to you have to look in the issues and think okay this might be a security bug and then you look into the comments and you see this it's a security back but uh searching is not easy and also

some people from the community have been very helpful and some of you in the list of attendees so yeah it's essentially the reconnaissance step that is yeah have you found difficulty in um so determining what what a protocol is supposed to do um whether it's documented well enough i i mean i know this this is something we pay a lot of effort um in cash it's basically my job to document the protocol um but i i haven't seen some of the documentation for other projects and i'm wondering how do you go about auditing a project that

where the documentation is sparse shall we say oh that's difficult uh because the first thing i want to understand is the worst case scenario from the project perspective what are the key assets uh what they want to product and for example if you have inputs that come from the protocol you know non-sales nullifiers or things like this uh i i want to understand who can control which input and how they come into play how to interact with it with the proof system um and what i also want to know is which parameters i fixed are fixed by design and which parameters can potentially be changed by

the users or the attackers on the or the application but just having a clear documentation or the protocol that matches the code is is hard to find i think some projects will tell you okay we have the documentation but it's for the previous release and what's also extremely helpful is to use consistent notations between the specs the paper and the code uh because otherwise you have to do this mental mapping between the notation and the code in the paper and so on it's nightmare out of time okay thank you so

i can give very general examples of things that could go wrong in the very general workflow of offer pro system so you have a program a computation then you describe it in terms of a circuit uh there's the optimization step where you turn it into a one cs or ir model depending on your proof system and then the actual prover it gets you approved which is integrated in the in the application that's maybe an oversimplification uh so first of all if your program is not secure in the first place then no matter how much z gain has no matter how much crypto you throw at it it won't turn it it won't be secure so you want the the program to be secure

you want the crypto primitives to be the right ones with the good security parameters and then you want the circuit to be equivalent to the program uh which sounds obvious but in practice is not always easy to realize it's not always easy to test i've seen a number of projects having vanilla version so a non-circuit version of the logic and having the zk the circuit version and trying to compare the two to have some kind of test vector so that's very very useful i guess and then of course see when you translate the circuit in a constant system then you want the constant system the cs to really enforce your

the constraints defined by your circuit that's what the definition of the constraint system and then in the proof itself a lot of things can go wrong for example having insecure components um or not having the right properties let's say if you have a commandment scheme you want it to be hiding and it's not fully hiding uh might be a problem um and even if your pro system is is safe in itself then you have to make sure that for example the application prevents the replay of previous proofs for instance um so a few examples of how you could for example compromise soundness so if your constraint system is not

effectively enforcing certain type of constraints certain type of arithmetic operations um if your keys are not sufficiently protected if your secrets are protected if the secrets from the trusted setup if you have trusted setup if they're not uh clear after the ceremony in terms of zero knowledge you have the risk if you treat private data as public data so in general it's pretty clear from the application perspective what is private what is public but it might happen that internally you tweet private data as public variable would be a problem and what i call metadata attacks is if you obtain knowledge um

if you gain some leakage on the internals based on the usage patterns of um of the other users so from the public option activity um you would derive you could get some information on the private variables based on the usage patterns that you see on chen and completeness so what can potentially go wrong so your constraint synthesizer might not not like certain types of circuits might not like like certain types certain number of variables and might fail to give you a correct constraint system also if you have multiple gadgets you want to make sure that they compose correctly between each other that

in terms of i don't know ndns in terms of data type um they're all compatible so to speak um and maybe more prototype concerns so because ultimately everything is software so you might have bugs that have little to do with crypto with zika proof but just you know classical software bugs for example encoding bugs uh bugs and dependencies so what we now call supply chain bugs uh it's not a needed to start setup but also in in all your dependency graph making sure that there is no like of non-verbal dependency even though it might not be a huge

problem depending on how you use it but have some level of assurance on who has control on the code of these dependencies because if i see that a small project with three stars on github is used in the ceremony of aleo then an attacker might be tempted to better using this uh this dependency uh and last but not least so the on-chain software if you have very fires of proof running on chen so we know that every other there's a big new disaster in terms of smart contract bugs um that's how it is but um yeah smartphones well what i want to say is that it's

already quite hard to do you know off-chain uh sdk proofs doing it on chain is even more complex so i try to break down the different components in you know as a kind of software stack starting from the bottom to the platform to the application and trying to distinguish the different types of input that's typically how i would try to reason if i had to edit project so one input is really clearly adversarial what is directly coming from the protocol like the the block number for example and what is hard coded by the configuration so for example um what type of curve you use uh the number of uh variables this this kind of thing

um and i tend to observe that the biggest risk contents of zkns are the abduction level whereas the biggest person of completeness and soundness are the the lower levels and each layer has its own type of risk its own types of sub components starting from the top here so in the application you may try to distinguish the key management noise management issues also as an editor i usually like to look at the unit test at what is tested what is not tested do you test the failure cases or only the success cases

how do you define the interface are there any potential situations that could be exploited to what extent can value be replayed so of course in the proven verifier there's a whole lot of components so you know hash functions prf algebraic hash functions such every commitment randomness randomness interfaces you might have uh non-uniform distributions to to simulate of course all the miracle 3 proof of membership logic that is quite complex but now people tend to get it right also the fiat chamier construction so here you want to make sure that you you hash everything that needs to be hashed um

and non-trivial components such as hash to curve polymer commitment where we sometimes found some bugs so and at the very lower level so you rely ultimately on your platform your language the version of your language the runtime your hardware the microcode all the dependencies the randomness coming from your system so i'm quite happy to see that today the randomness situation is much better than the 10 years ago we tend to have quite reliable crypto random generators but you can still find some cases for example i've seen recently that the there was some bindings there wasn't use of randomness for

certain types of architecture was not perfect in case of a non-architecture so we still find some time to time randomness issues what's important maybe from a designer perspective and from a documentation perspective is the contracts between your different components uh what are the preconditions that you guarantee um so and what do you guarantee to um to the color of your function uh a very typical example is the the group membership checks so when you receive a number that is supposed to be a scalar in a given range um where do you make this check so you can

make it everywhere all the time but you don't want to make the check at every place so what i see many projects doing is when they instantiate a group element from integer they do the check once and then this group element will always be enforced to be an actual group element and likewise if you need to check that a group element is non-zero you want to make sure that well typically the right thing to do is to do it as early as possible when you receive it from from the application but it doesn't hurt to do it multiple times in case a function is used in different contexts um we we tend to um to make another type for the the non-zero um thing if we're using

a typed language like rust okay yeah that's the ideal case because then you're sure that it won't be it won't be zero in general refinement types are really useful in crypto so to finish i'd like to go through a few examples of bugs so not my complete list and not all the all the bugs that have been ever found and maybe not the most interesting ones so at the end i'd be happy if you guys can share some examples of bugs that you you've been aware of so this one is the one i mentioned before the the case of a missing overflow check so in that case a nullifier was not

verified to be less than the modulus so different distance nullifiers would be accepted that ultimately would reduce down to the same modular value and the exploitation scenario here was uh the double spend so another missing overflow checks in that case of a public input um in uh which project was it in or this and another one so this one is interesting i think uh could be mentioned it to me recently so in this project it was initially the check was initially set here at line to 22 but the developer removed it because they believed that it was not necessary

whereas apparently this check was indeed necessary and i i think that this change was not accepted so you also have to be careful of people who want to optimize the code to save some gas and remove some some useful checks i i've got a good example um in the um the orchard protocol which is about to activate on z cash um so an earlier version of the circuit um that there's there was this requirement in the spec that um a [Music] particular um

value needed to be um a non-zero group element or a non-identity group element um this is the if you know the zcash protocol it's it's gd um and we had used the type for these values which excluded xero yeah and that was checked correctly but what we didn't do is the circuit didn't include that check for non-zero so all of the witness calculation was was enforcing this but the circuit itself wasn't and how did you find the bug um

oh so um an auditor uh it was credits actually um they they didn't notice the bug they um they actually thought that we had um implemented this correctly and then they said in the first version of their report that this is a potential problem but you've influenced it correctly and so i checked it no we haven't so for another type of box of this one is the in r1cs um a constrainer system and it's a case where the inverse property of an element was not

enforced so you could sum it to an element that was not the inverse of the one it was supposed to be the inverse of and the proof would have been accepted because it would not have enforced that that constraint i think it was uh um also reported as a rasek advisory um it wasn't in hogwarts so i mean they have very very good code base but uh [Music] and i think you know like in every project uh you should not judge the quality of a project by the number of bugs you have because it might just tell you that people have been doing a good job you know looking for bugs in the first place um was projects for which no one reports bug

what maybe it means that no one is looking for fallbacks so do i just don't want people to get around the more bugs i find the more confident i am yeah this one um it was created to um to copy again so it was in uh merkel michael tree computation and it was more language uh issue this the wrong symbols were used for the equality check and then the quality check was not done so the merkel route uh was not correctly compared so an incorrect miracle would be accepted and this could be used to to get invalid process accepted and it was fixed quite easily

so this is the bug i referred to before so this kind of bug already rare because well i don't mean to say that there's no bugs in the papers but the bugs and papers are quite hot hard to find so in that case uh ayat gabizon i found a problem in the paper in the description of the trusted setup and the problem was that some values that were actually toxic and supposed to be clear were not cleared and it could later be exploited to um to the double span ultimately yeah is that correct that's exactly correct yes yeah and i think so the zcash team did a very nice job for someone disclosing this to

the project raising the same code base because now we have the problem that once you find a bug in your code that it might not only be your code so in terms of disclosure what do you do quickly fix it for you but if you fix it and disclose it then some people might exploit it to uh or expect other projects so you want to try to be as responsible as possible but also to product your own project so that might not be easy to manage yeah we had to basically um to define some cutoff and market cap of the projects that we wanted to uh to inform yeah but if i had not found that bug i wonder

when it would have been found if at all um so i the the issue was that the bctv14 paper didn't have a complete security proof and we i think it would have been found one by other or the other because um it wasn't just a security proof right like the protocol wasn't in the main body of the paper yeah yeah exactly it was an appendix um and it was assumed to be secure based on being similar to phdr 13 um which which did have a correct security proof well correct as far as i know

um so i think i think we were always going to um try to produce a rigorous proof and check it thoroughly um so it's a matter of time before that book was found um yeah yeah i think that we didn't really have a lot of trace but to use bc314 because it was basically the only improving system that that met our performance requirements when we launched zcash i wonder if we shouldn't spend more time reviewing proofs

and papers generally as opposed to to only only code yeah definitely and you know when papers submitted conferences uh and reviewers are doing their best but oftentimes part of the proofs are in appendix and uh yeah it takes many hours to write your proof correctly so i think part of the issue in that paper it was it was trying to do a lot um it was it was trying to do too much actually because xerocash is a complicated protocol in itself and the proof system that was a modification of phdr 13 should have been probably a

separate paper i don't know some degree yeah oh cool yeah to some degree i don't even really think it's the job of reviewers to be finding these kind of cryptographic bugs like the job of a reviewer is to decide whether a paper is interesting or not and it's more the engineering community that has misunderstood that i agree yeah yeah i i don't rely on peer review to find bugs because it doesn't and i've seen in the case of npc protocols or interactive protocols some proofs being written with certain you know communication assumptions which are not necessarily you know

correct in practice so yeah so the next bug um this one is marty application level um it was disclosed by a stack and it was about the noise management about the choice of nonsense so the proof system was fine apparently it was just the the way inputs were chosen so like in the first example they think they use nullifiers instead of account nonsense and in the second one um the notes was not included at all in the in the encrypted

knot um uh this bug one i don't want to call it a bug but it's uh a scenario whereby you cannot completely break your knowledge but you can exploit some you know usage pattern information and leverage it to [Music] try to compromise is the guinness but um i i i i have to um i have to be careful about how i phrase this but um that this this paper is a very poor quality paper they do not understand the protocol um the original attacker

relied on a property of the protocol that it doesn't have and when we tried to communicate with them about this um let's just say that that communication was not very productive um i think the problem wasn't on our side yeah yeah the paper is a bit um yeah surprising in terms of the claims being made but uh the claims are um i i'm pretty sure false nonetheless this type of attack might be extremely relevant if you know that

two inputs might be similar or might have some type of relation and i i don't know if the proof is if the security proofs uh take these potential leaks and uh into account um like for example in case of shielded transaction you know the potential alternation between two amounts you know this one is bigger than that amount um yeah it's certainly very difficult to um to analyze a a protocol that has a transparent aspect when you're trying to analyze it for privacy yeah

and we've we've taken that into account when we're designing the um the unified addresses for the new version of nu5 um the next upgrade is zcash so the the default privacy policy for that if you're using a unified address and a transaction is for everything to be private okay can i think is it the last no maybe not the last bug um so this one was kind of zero knowledge bug that was kind of impacting zikiness um but not very clearly so they were missing some you know random blending factors so i think that on paper

uh it kind of compromised your knowledge in terms of the proof not being valid anymore but i'm not sure and i don't think it was really leaking data in the in the in the proof in the blog proof um maybe plonk people will you know it's better than me but um that was my basic understanding of this back it doesn't mean it should not be fixed but this one was in again in a disclosure from from aztec so it was a bug in the mercury competition that

was a dos bug but a kind of bad bad one in the sense that it could potentially freeze the ability to verify sdk and zika lapse um so maybe i can skip the technical details it's a tree competition bug that that blog post i think um it actually it wasn't um entirely obvious from the summary of the post but there were two books there i think the other one was just on this book okay and maybe this last it's not because it's interesting uh not because it's clever but it's when i recently found in the implementation of the cairo language and it's a problem that some valid

signatures are being rejected and my understanding is that the developers believe that the risk was negligible whereas from my perspective it's not that negligible is 2 to the power -54 so meaning that you can forge a signature that would be actually valid but rejected by the um by the on-chain uh contract derived from for the cairo implementation i haven't yet got the feedback from um from the carrot team i'm curious to know what the what i think of this and i should do the bug ones that then force the sun values to be less than 2 to the

number of bits in the exponent by the models as opposed to being less than the the modulus and i i don't know why they do this maybe to save um save gas is this they're doing it in a circuit are they doing outside the circuit because because um doing a track against a specific value rather than a power of two a circuit is about um there's an optimized way to do it that depends on the number of sad bits but yeah that was my guess it's yeah it's roughly about one and a half times faster so maybe it was a performance type

um and other types of issues that we've noticed or that we've thought about uh for example in protestant commitment pedals and hashes making sure that your bases are unique and correctly generated within situations where you know the padding when the hashing or commitment there was no no padding at all because you accept a value of fixed size but at some point then you start using it with a value of variable size then you want to have padding otherwise it's completely insecure some small bugs that we noticed was for example in the poseidon hash function linear algebra step

so i think one vector matrix product was computed as matrix vector or the opposite so it wouldn't reduce the security would just make two dimensions incompatible um and also when you fiat sharmier stuff so make sure that everything from the transcript is correctly included in the fiat mirage yeah i mentioned the compass ability before side channels um i think in most cases people try to people make some effort to avoid you know patent constant techniques but most projects many projects will tell you that uh they don't they have no guarantee that is constant

time is not designed to be fully constant time regarding with respect to the private values so the question is when how could this be exploited or not same for the potential ram leakage if you have some value this is not zeroized but to be honest i don't think you have to worry much about it but at the same time i don't want to tell people okay don't worry about it because they will find the one case where it's important uh and another big class of risk is the speculative execution leaks all this spectre type of attacks go back to the that page so that there's a really interesting example of the um the

fiat xiaomi problem um in a an election protocol that i think was used in or going to be used in swiss and australian elections oh yes yeah um so so they they weren't hushing um the the instance um and so swiss law has really um strict transparency requirements for software used in elections so it's found in the swiss election but the australian laws are the opposite though it's basically security by uh obscurity enforced by law um and so yeah um they don't do what australia did for their election

oh yeah this swissy voting business was quite a story so yeah to conclude on this um um well i i mean this talk comes from a frustration i had of not finding bigger bugs than i that i found and also from the realization that there hasn't been that many that many bugs found so i tried to understand why so maybe because all the people in this ecosystem are pretty smart they're not only know what they're doing they want secure code presumably the use of domain specific languages like carol leo and noir will make it easier for people who are

less experts to write safe code because dsl will do part of the work for them and also maybe one reason why we didn't have many critical bugs is that there's a very narrow text surface in terms of what the attacker can control and what the proof exposes as a result so in terms of constant size uh constant side proof uh however what is still worrisome is that yeah very few people will understand zika snarks uh at the level needed to find bugs so even fewer people can really understand the code and have the time and knowledge to find these bugs we probably need more tooling i know

that there are some efforts e-forces going some people trying to to do fuzzing differential fuzzing i don't know if formal verification can help usually not a big fan of verification but doesn't mean it's completely useless and also i think it's just the beginning uh in terms of zika technologies there will be much more projects using zk proofs um so which means much more value at stake which means more incentive to find bugs and maybe more incentive to withhold the bugs and exploit them as opposed to disclosing them so we want to avoid some situation and in the you know defy a web stream business where uh you know you know you know what

happens thank you um for attending thank you for the the discussions uh and i would like to thank some people and companies who helped me with uh discord so leo protocol labs um kobe adrian lucas and i'm happy to use the time left we have for taking more questions yeah dara did you have another hand it might be a it might be a hold over yeah yeah it's just left cool um ajp thank you very much uh really really fascinating talk um on your last point you mentioned you know vulnerability and high roi for people to exploit uh bugs

um you know just just try it don't don't open a short position that then later gets created because no one knows about the vulnerability just joking we shouldn't joke about this since you know for anyone who's watching this in the future this is a this is a joke about um you know a six i think what is it 625 million dollar hack of a smart contract bridge that uh the hacker opened a short position for uh planning for the hack for the vulnerability to become more widely known apparently it wasn't uh for six days and his short position was was liquidated um kind of hilarious um but uh anyway so on a yeah on a centralized exchange which is going to be profound yeah um

but anyway back to that back to the topic uh jp thank you very much um and what we can start questions does anybody uh from the audience have have any questions to start us off i have a couple but um i want to turn it over to folks who are listening first okay i'll start with mine um so jb at the very end you mentioned a couple of things um about you know like tools that can help you know with you know kind of um you know aside from auditing which is kind of an active preventative measure that's kind of a weird way to put it but you know you you know someone to go in and look at your code and audit it you know you mention these tools such as fuzzing and formal verification

um are you seeing or you know is there do you think in your mind you know starting to be more standardization or or you know uh around some of these tools you know at alia we kind of like built an in-house fuzzer for leo which is our specific language but it feels like to your point in this call you know in this talk there's many of these same similar bugs affect multiple projects and it seems like it's crying out for some kind of industry or you know higher level tooling that people could use but have you seen anything like that standardization around these tools or is it still pretty interesting it's not really budget tools but i kind of recall some people mentioning uh ids to standardize encodings of

constituent systems of you know polynomial constraint systems that could be compatible with different implementations of i don't know graph 16 or oblong or marlin what might be also useful is to have a a kind of standardized interface to allow for differential fuzzing so let's say you have two implementations of marlin and you want to make sure that given the same parameters a proof that is accepted on the first instance would be accepted on the second and likewise would be rejected on both um so i have no idea how how difficult it is um

but it it proved very helpful in the context of basic crypto libraries with projects like witcher proof um and also going back to ear which proof it's a project where you fuzz an interface but it's kind of smart further in the sense that let's say your first ecbs interface you will you will know which type of cases are error cases should fail for example if you send a node zero signature so if you know that you're talking to a graph 16 or plunk or mind improver you would try to send a mile from proof that is created in such a way maybe to fool the system or to make it crash so try to cover all these edge cases

but before doing this kind of fancy fuzzing verification stuff i mean no it's not about how much audits you throw the project it's you know about your internal you know security as dlc process starting with things as basic as tests as unit tests um as documentation and integration tests so you know first have write it if you need test uh maybe a new ci by pipeline and then start doing some fuzzing um but don't waste your time investing in formal verification before you have you know a good uh state pipeline so for footing an issue with fussing cryptography is

that um often the the cases that you're trying to hit um have very low probability um when given random input yes even to the to the point where it's difficult to get to the point in the code where um where the error where the bug actually is um so i mean i know a potential way of getting around that would be to use say an smt solver to um to try and solve for inputs that get that get you further into the um the program um do you never have any other approaches do you think that's a

practical approach yeah yeah i agree that first thing i've seen people trying to first have functions i mean which is completely useless because the struggle and programmer um well i also found very useful i've seen some projects organizing internal audits it's like you know for one week you create small task force and people who know the code and they really focus on finding bugs and maybe developing some new tools um and if you if you hire like external auditors you want to make sure what first of all they have the capability to capability to help and maybe that i get enough time to

well understand what they're looking at what can go wrong and that you don't start directly by looking at the code because it's not useless but not a good original investment yeah i mean i i would say you always have to spend as much effort developing tooling as um so writing the the proof system in circuits in the first place yeah um because otherwise you you're not going to be able to to understand that visualize your circuits um and yeah that's definitely been a problem with zcash we do have some tools but not enough and not enough time to build them yeah

and knowing where to focus your effort because let's say comp a project with the the complexity of audio with the multiple layers of complexity in the multiple probing systems then you might have perfectly fine uh you know zika profs and uh constant systems but then at the application layer you forget one minus sign or you forget one variable then we we just found a bug in um workshop that was it was actually a completeness bug um but um we'd made a change to the the protocol um to so that there were

instead of having one incoming viewing key for notes that there were two possible incoming green keys um and we hadn't updated the implementation um so sometimes it was using the wrong key um and therefore the the proof verification was failing um so so we had a little bit of a panic when we thought this was um uh some complicated uh subtle bug in the circuit but actually it was just using the wrong instance don't you think there's some level of security by obscurity because it's so hard to approach it takes so much you know experience that most likely these bugs would be found by the teams by the developers as supposed to buy no bad guys

i mean in principle a bad guy if if they're willing to put enough time into it they can learn a protocol they can learn an implementation and they can find anything that you could find um it's it's really difficult for them um but how do you know that for example that the attacker isn't um some former employee or um yeah or an order for that matter um yeah so there are enough people who could potentially understand this stuff that you do have to worry about even if it's unlikely yeah i think it's interesting going back to the point that you talked about both of you with regard to tooling um it does

feel like that you know because many of these systems are so nascent um you know there's an opportunity to build better tooling as you said there just even visualize in some cases like what you know what is happening and uh yeah i mean and i was thinking about the grants you know the ecos the kind of zk grants program that you run like something like that feels like a perfect thing for like some kind of grant for a team to go and build something that would be beneficial for you know for all and i think you know at the end of the day what do they say you know kind of at least not not with regard to things like tools like fuzzing but with regard to testing certainly these basics that we kind of like if all software engineering you know you know are just

good or you are just generally good software engineering practices i think it's it feels like there's still quite a long way to go just with regards to kind of enforcing and doing the basics across the board um and it's difficult go ahead um choice of programming language i mean a lot of code now is being written in rust there's still a lot of code in cfos plus c um languages uh without strong type systems um yeah it kind of makes me nervous so much yeah actually on that point i have a question so what i mean you audited i think if you it's audited systems that are both russ and c plus plus is there any other languages represented jp that you've systems you've audited

well i've seen some projects using uh go or i think even javascript or typescript but most of them are in in rust now so oh and now you have zebra from from zcash uh um [Music] like all the actual artworks is in rust i think rust is very good language for this type of project got it yeah yeah i was just curious you said basically you answered the question at the end there i was curious if you had kind of a preference or you thought that certain languages were more potentially practical for this problem and sounds like i mean as most people have already concluded russ is certainly one of the better better ones if not the best

yeah i mean the there is um okamo being used by owen labs yes we don't have uh we don't have isaac here unfortunately to to tell us the benefits of ocamo which i'm sure many i'm not you know very educated and i i i really like her camel um yeah if you wanted a garbage collected safe language you could do a lot worse than a camel um obviously a little bit more difficult to find people are familiar with it yeah now it's interesting i mean like here this brings goes back to your point there around the expertise and jp you made this point like the security by obscurity just simply because it's too obscure for all but you know some tiny sliver of the population to ever understand what's actually

happening under the hood um and yeah i mean i think it feels like i mean it do do you view this as as something that i mean maybe this even extends beyond zero knowledge but just cryptography in general do you think you know these systems get more complex as there's more moving parts as protocols kind of extend up the stack um you know how do you address that problem where you know there's very few people and you even mentioned this you know when he said hey the bet the best position people to spot bugs are the teams themselves but in many cases even the teams you know that aren't working on separate pieces of it and there's sometimes no one actually seeing all of the parts as they're fitting together so how do you

think you you address them well what scares me is what i call state machine bugs because ultimately you have a stateful system and entering you know after a sequence of events in a state uh that is insecure but first of all you have to know what is in a secure state and how this insecure set will interact with your proving system and what role your proving system will play and if i yeah i take the case of alio it's an example where i was really trying to reason about okay what type of viable combination what type of input would be wrong to have here and how can we make sure that this will be rejected

detected um it was very very clear to me because it's like when you analyze consensus consensus protocol on paper it's really to be easy to understand what happens and then you simulate it you're like oh [ __ ] it's crushing what happened and there are many types of bugs that you can only observe by you know running it in practice because it's too non-linear to anticipate what's going to happen there are way too many different uh possibilities um the the the bug that i just mentioned about and the orchard circuit the the way we actually found which part of the second it was well it wasn't a second

bug but which part of the instance was wrong it's just commenting outputs the circuit seeing whether it passed or not um so yeah it's some kind of automated way to do things like that or really useful what also might happen is uh you know what you've seen with crypto because suddenly when crypto becomes easier to use you have better you know interfaces better libraries then everybody starts using it even people who don't know what they're doing so perhaps the same might happen with you know ez caprara spring systems when they become much easier to use where you have all these dss and everybody can be a cryptographer

everybody can do zk systems um and i've seen some projects already that look a bit sketchy to me they claim to use zk technology but you don't know what they're doing and you don't know if they know what they're doing i mean it's inevitable that that more people will learn the technology and therefore there'll be a larger pool of potential attackers so it's kind of a race against time to build this this tooling these languages that allow us to to avoid the bugs before that happens um it's it's definitely not a bad thing that that more people are learning how

to um to to do zk stuff um even though it does increase the pull of attackers yeah or maybe now is a good time to highlight some of the great work that uh anna and kobe uh have been doing on the zk hackside trying to onboard new people into this world and getting them interested in it and uh yeah hopefully yeah hopefully some of those people will go on to start cool projects and hopefully some of them will build tools that help make things more secure and maybe some will even become auditors go work for you jp cool um anyone else i guess we're down to just a few folks here anyone else have

any um final questions for jp all right awesome well um thank you very much jp i really appreciate um yeah we all really appreciate you coming on uh zk study club today i think everyone learned a lot and i really enjoyed the conversation so thanks again for being here thank you alex thank you everyone