ZKPodcast: ZKPs, Audits & Security with Benjamin Perez from Trail of Bits
3 Apr 2020 · 54:03
Benjamin Perez of Trail of Bits joins the Zero Knowledge Podcast to discuss how crypto security auditing has evolved and the distinct challenges zero-knowledge proof systems pose for auditors. The conversation covers recent bugs and vulnerabilities found in zk-SNARK implementations, side-channel and anonymity risks in privacy-preserving systems, and what auditors look for when reviewing zkp code.
Speakers
Topics
Transcript
[Music] welcome to zero knowledge a podcast where we talk about the latest in zero knowledge research and the decentralized web the show is hosted by me Anna and me Fredrik before we start in on this week's episode I want to tell you about the zk summit the zk summit is a biannual event focused on zero knowledge research optimization implementation ZK use cases Universal trusted set ups no trusted set ups recursive snarks cryptographic
primitives privacy and math this will be the fifth edition it's put on by this podcast the zero knowledge podcast it's happening on March 31st and it's an online event attendees will be primarily researchers cryptographers practitioners and founders working on zero knowledge research in the past it's been an awesome event I can't wait to see what it's like online so if you're interested find the link in the show notes or look for the ZK summit on crowdcast for those of you who already applied for the event you should check your inbox you should have received actually an invitation to this just the date again it's not happening on March 31st 2020 event starts at 7:00 a.m. PST 10:00 a.m. EST and 4 p.m. CET so hope to see you there
and now here's our interview with Benjamin Perez from trail of bits so today we have been Perez from trail of bits welcome to the show Ben hey thanks for having me and we also have Frederik hello Anna so you may be familiar with trail of bits as they are sometimes sponsors of this podcast this episode is not sponsored by trail of its in fact we've had JP on in the past JP is a colleague of Ben's who also as an auditor at trail of bits but when we had JP on this was like peak 2017-2018 crazy ico time and in that interview we actually got a chance to
cover like what the role of an auditor was what the company was up to and it's been a long time since then and I think what I want to do with part of this episode at least is try to understand better how the role of the auditor has evolved in the space because it is no longer 2017 2018 with the ICO boom so what has changed so maybe we can start there Ben Oh actually before we start there why don't we learn a little bit about you Ben what's your background how did you get into this sure so um originally I was just like a math person who is like loosely interested in cryptography I started doing a PhD in like post
quantum crypto and that was at UC San Diego but eventually left for industry well for trail a bit specifically because I wanted to be working on projects that were a bit more applied and like of course I have a soft spot for the theoretical research that academics work on but I really like building stuff that gets actually like deployed so that's kind of how I got to trail of bits what when did you actually join I joined in like April 2018 okay so would you say when you joined was it still like very IC o---- focused it was it was actually kind of like a culture shock for me because before coming to trail bits I didn't have a lot of experience in blockchain okay I came from the crypto
side so when I started we were getting all these like you know whatever coins and just like totally like wrecking them finding all these bugs actually one of our tools kind of came from the fact that we were just able to like print free money in a bunch of these alt coins and we're like well I think we can automatically just detect this and you know find this stuff within like 30 minutes so we did and that was like a lot of those early mistakes in that space kind of led the development of our tools so yeah I think that's interesting I mean we talked to JP about some of these things too and like some of the things that we're evolving at the time and I mean I think trailer bitsa has been on the forefront of a lot of this
stuff but even from the point that you joined to now how do you see that changing like is it still like I have to imagine that it's less crazy you know get-rich-quick scheme stuff and more the companies who actually raised money who actually are building something now yeah I think that's exactly right so um you know back when I started like I said we were just like kind of doing these like really short quick audits for random I cos I mean not random like I mean these were like legit come we didn't do any scams but like now I think what we see is is we still get just as much blockchain work as we did back during the ICL mania but these are companies that are like really at the
cutting edge of new research in the areas of why proof of stake zero knowledge stuff other like really advanced cryptographic research so I think it's actually got a lot more interesting these companies are like amazing to work with and in some sense have like more challenging problems that they're working on as the type of work changed much from smart contracts to like underlying tech I mean I know we use parody we use travel bits to audit ourself every once in a while and we never do smart contracts it's more like audit uttering clients or uttering like core libraries as that type of work changers is still a lot on the smart
contract side I think that we've seen a slight decrease in the amount of smart contracts that we see we still do get a lot for sure so like are the tools that we built out to do that still have a like a lot of use but a lot of the companies that we're seeing now are building out these new blockchain protocols in like rostered go and so we've actually now started to build up tooling for auditing Austin go code bases and also because a lot of these companies are doing stuff that's like really novel with cryptography a key part of the audit these days is actually kind of looking at the papers that these people write and making sure that like it actually checks out from a
cryptographic perspective um so I would say it's less yeah kind of analyzing this like well when you're on the blockchain it's it's a very confined environment you know it's all solidity running on the EBM but in these cases there is sort of like a lot more that can happen so I'd say that these audits can be like a bit more dynamic I mean there's basically no white paper or like blockchain white paper that I've ever read that actually proves what they claimed in the paper I imagine auditing that has to be I mean it both interesting but also hard like actually say you know this whole yeah I mean there are different degrees of it of course so like some people kind of come in with their like you know hey
we rolled our own like verifiable random function or whatever in you know like here's what we think works like kind of good luck you know hunting it those are actually sometimes the most fun but you know there are a lot of people in this space that are being really cautious that hire like you know phd's in cryptography those folks tend to point to papers that have seen some amount of peer review I think the history of cryptography we've never seen such a like a quick turnaround time from academic publication to deployment and and there are a lot of subtleties that don't really like manifest themselves in the paper so there might be a security proof but there also might not be a part of the paper that says oh by the way here
are all the edge cases that you need to check in code and if you fail to check those any of them someone all the sudden can Forge signatures or whatever so there's just like a lot larger of an attack surface do you think like the character going back to that you know that earlier episode that we did where we talked about the character of the auditor do you think that the makeup of the team has changed are the people that are actually capable of doing these kinds of audits different than the people who would have been maybe focused more on those early quick ones I think I think we still need III think that there are more types of people required now to kind of do a comprehensive review of
these systems but it's not like the people who were doing the early blockchain audits are like now all the sudden like have really dated themselves you know what I mean like I still do see a lot of audits where we need to do it like smart contract audits but also I think that the kind of person who's good at just like poking around a codebase and like figuring out the ways that it breaks you know um even if what you're doing is very advanced cryptographically you know maybe 70% of the bugs are still just going to be someone implemented some logic bugging code that it doesn't have anything to do with it and watch me talk hopefully about that later with some of these new attacks
from dan bonanza cash but there's still a huge tax surface at just like the like app development level got it so you I know that I mean trailer bits has created a few tools to actually like catch these bugs but were those tools originally more for like solidity code like did you have to do you have to change these tools to actually work on different types of programming languages yeah so some of our code is very solidity specific or some of our tools are very solidity specific so the three main ones just totally kind of go over it is like slither which is a static analyzer that can like just look at the solidity source code and find common bugs so
that's very solidity specific because it finds like anti patterns in writing solidity code and kind of like warns you about them then Echidna is a fuzzer so there are fuzzers for like a wide variety of systems but basically the idea is the same for all of them which is just like you start calling the functions that are publicly exposed in the codebase with sort of intelligently picked random values and then you hope that at some point you for something to crash so we have fuzzers for a lot of different things but the kid nut is the fuzzer built specifically for EVM I see the most dynamic tool that we have
though is Manticore which is the symbolic execution tool that we have that has support for a wide variety of systems one of which is EBM so that is a bit more flexible and we can use it in audits that aren't strictly within the etherium ecosystem you also have a bunch of other stuff like binary ninja there's a bunch of other stuff that deals with both assembly and we talked I think we touched on this with JP as well being able to lift code into LLVM ir and then doing analysis on that all this stuff I so the reason I mentioned the album thing
particularly is because it suddenly allows analyzing rust code web assembly code a bunch of other things because these are all things that go through LLVM in some way totally yeah so a huge part of what trail of its does that like so I think that we're really known for these like audits that we do but there actually is like this whole other side of our business which is government-funded research and that's where we get money to like build binary analysis tools binary translators even like symbolic execution tools like Manticore that was originally a government-funded project we have yeah we have quite a bit of tooling around that and actually what we're gonna be doing with zero knowledge for DARPA
coming up that's going to use a lot of our binary lifting tools as well so you know yeah we can talk about that more in a little bit and so my last question about trail if it's specific before we go into the ZK stuff is about like if this the question comes because I had a conversation with Dan the CEO of trail of bits Dan Guido like I think a year ago maybe where we talked about this idea of doing simulation work like actually trying to model things past just the code like especially in cases like POS systems like actually explore what the outcomes of the economic models
could be and I wonder if that's something that you guys do or did or plan on doing yeah so this comes up in some audits that we do where we talk about economic incentives with the people that we're working with so like obviously like you need cryptographic security in your blockchain and all that stuff but you also need to like incentivize miners and all of the people involved to do the things that you want them to do and I think that in some cases especially with these like proof of stake systems you run this risk if you're not careful of being able to have the the folks making decisions about your network susceptible to basically
bribery or sort of buyouts and there's actually a really good paper on this from Phil Diane and some of the folks over at Cornell about dark douse it's this notion that you can like temporarily sort of lease your key to this decentralized network of like malicious actors that will like pay you to use your vote to kind of will launch attacks against the network and it's so yeah this stuff gets really complicated and it is sort of this interesting intersection between cryptography and economics and actually we offer jointly with another organization economic and
like cryptographic audits of blockchain projects interesting so that's some like very exciting work that we're doing yeah to me cuz to me that so that's that actually goes outside of the role of what you think of it when you think of a tech auditor it's so many it's almost like consulting then you're like giving some further analysis there past the actual code yeah it is a bit more outside the scope of what we would normally consider on it fortunately in these cases it's sort of within reach to sort of mathematically model what people do this is a less like open world system than like you know the US economy or
whatever so it's easier to kind of sit down and be like okay how are people getting paid in the system how does that payment incentivize the right behavior and all that stuff yes so I think I mean this is something that we're seeing you know a huge influx of these incentivize test nets it's it's basically only to try to test the crypto economics and the problem with them is obviously that you're not going to get the same kind of engagement and behavior as in a real network with billions of dollars at stake if you just have oh you get 50 bucks if you win this thing so it's sort of it's a weird situation and I think like Tarun who believed had on the show him then his company
basically exists just to try to build these models and simulate things that try to build tools to to see if we can test script economics but it it's actually seems like a really hard problem yeah I think that you can kind of do some back of the envelope you know calculations to see what the incentives here look like but actually like running a simulation of that system I mean that's a it's a substantial undertaking and requires a lot of expertise in you know distributed systems cryptography economics on top of having you know the text app to do it so um yeah who do you partner with to do this yeah so so the
service is called main net 360 and that's yeah this joint economic insecurity or that we do with the prism group there yeah a group of economists who do some really great blockchain work and can help us sort of fill in our gaps where we don't necessarily know economics at a deep level I mean we're computer security people um so yeah that partnerships really exciting and I'm excited to see where it goes all right next up let's move towards the ZK stuff I want to hear a little bit more about how true like first of all I want to understand why is trail of bits interested in zero knowledge research everything we're talking about
looks more like code audits and solidity and EVM and even modeling none of those things are necessarily zero knowledge so where does that interest really come from yeah so I think the trail of bits is kind of unique amongst organizations that do these sorts of things because we're we have a lot of people who were formerly academics I myself like I said started a PhD and decided to leave for industry and as a result I still have this like soft spot for really cool research problems in cryptography and so personally I like to do audits and work in general that involves what's exciting
in cryptography right now and in my opinion that's these privacy preserving tools like zero knowledge multi-party computation things like that so yeah I the push comes from within but also just that like the good blockchain will work right now is taking these privacy concerns seriously would you say that it in this case are you saying that sort of the auditors or like some of the yeah they're like kind of the staff got very excited about this and started to like pressure management to like find these projects or do you feel like the projects emerged for you I mean I think that we built up a reputation for being you know good with blockchain from the
ICO mania which is you know when you talk to you JP and then that kind of put us in this good position to audit the second wave of block chains which is a bit more you know cryptographically oriented and that combined with the fact that we have this great crypto team with a lot of expertise in zero knowledge and multi-party computation kind of like it just made sense to start looking for those types of projects so what are those projects like what what does an auditor do with a zero knowledge proof system I mean the in academia you have you know people creating some of these systems and then you have other like other either implementers or other
academics analyzing them and looking at through the math but is that like I guess the question here is like it does that need an audit in the traditional sense or is that more like you guys are kind of stepping outside of the realm of being an auditor here and starting to like participate in this research out make yeah I'm just trying to figure out if that's like actually the same job yeah so I think that you know what an auditor is is flexible we do what it takes to make sure that the companies that were working with are as secure as possible so when I see a system that uses stuff that's really cutting edge like this I usually spend a lot of time you know like I mentioned earlier
reading the papers making sure that the code actually adheres to what they said they were doing in the paper and kind of finding all of the holes and edge cases that they hadn't necessarily thought of I think the transition from something that you write as like a theoretical cryptographic construction to a thing that exists in the real world in runs unreal hardware that gap is huge and so while we don't necessarily find like a groundbreaking bug in a course your knowledge protocol that has but you know has a security proof or whatever those are rare but a lot gets mixed up in that transition to code and I think that that's where we
really shine because we we understand these papers and we understand the ways that they might break when they're actually being deployed yeah there's like a lot of different layers here right we're you know compared to what we talked about white paper it's like these are not white papers they're actual papers and to be an actual paper you also need to include proofs so I guess like yours you're at least coming from the luxury of having a system that's peer reviewed and you know to some degree proven on paper but then sometimes you know that the paper or right or like most recently like it seems like most of the paper writers are actually implementing this thing as well
so you have the implementation of the paper usually from the same authors and then you have a user of that implementation and things can go wrong in each of these stages right the paper might be wrong the implementation of the paper might be wrong the usage of the library might be wrong or it like complete misunderstandings about what the security you know guarantees actually are in what in what level do you work mostly is it on that last step or or have you worked even with some of the authors of these libraries that audit that libraries themselves we've certainly worked with people who are putting out cryptographic research papers and are writing core libraries those are more challenging audits for us
because as people are like really smart but we do find bugs you know and people again they forget to check edge cases and these systems are just they're so complex they rely on so many different primitives you know if you're doing this or knowledge you need your like commitment scheme to work you need the list the circuit compiler to work you need to do pairings on elliptic curves deep like any one of these subsystems failing is going to like totally sink you and so there's just a lot of space there for finding bugs but I also think that a big concern that I see in the space is we've kind of moved past the phase where only you know a couple hundred academics understand
how's your knowledge proofs work this is gotten a lot of hype and now new projects are going hey like why don't we roll out a Zeke a snark or some form of zero knowledge proof and those people are maybe not as cautious as the people who are writing these papers because they're not as familiar with the ways that crypto can go wrong this is something that I see a ton happening where it's really interesting with this podcast and like being out there in the world talking into crypto projects like when I talk to people who want to use this stuff they're just like oh this new thing came out we're gonna use that instead and they start like they start integrating it and I'm just like holy [ __ ] are you crazy
yeah and then when I talk to the author it's like oh yeah we'll see where this goes in the next five to ten years like that completely different expectation levels and I think that you know of course it's all about striking a balance right you know the one hand crypto research doesn't do anyone good if it sits on the Shelf forever but rushing out to deploy one of the like 10 zk papers that came out in 2019 that's a risky thing as well and I think you know this isn't just a problem with zero knowledge of stuff I've seen a lot of hype around these verifiable delay functions recently which again like really cool stuff and really legit people are working on this but all the
sudden now you're blockchain might rely on some cryptographic assumption that is relatively new and we just don't know how robust that is and I think that the good people in this space are you know expert cryptographers but they also understand what they're gonna do if something goes wrong in one of these protocols so like easy cash is a great example of people handling this like absolutely the right way you know there was a bug in that paper that lets people Forge Z cash and they were able to fix it like like they just handled that vulnerability disclosure exactly how you'd want and stuff like that's always gonna happen
you're always gonna have bugs in your code and I think that what we what I want to see is is that you know people deploying this really like new somewhat risky stuff they just they have a plan and they're gonna handle this like the right way yeah we did an entire episode on that with Sean buh that will stick in the show notes this is like from last year that was the vulnerability that was found in kind of the original implementation the live Pete of me that's that this was actually from paper to the first academic implementation incorporated into a project and then it was found that there was something in that first implementation that had been sort of overlooked and that caused this vulnerability to emerge yeah exactly I
mean and this is the sort of bug it mean so when when Cray Lovett's writes up a report but we have the severity of the bug and the difficulty to exploit the bug right so you know you might have like a really like critical vulnerability that also requires someone to be like extremely advanced to exploit it and bugs like the one in C cache is like one of those things where they're like a hundred people in the world that could have ever found that bug and like twelve of them worked on that project or something exactly exactly so like it was handled exactly the right way but so the things that I worry about more are like what happened with the Swiss voting system so this is a voting app that used
zero knowledge proof since several steps of the process to demonstrate that the voting authority wasn't either adding malicious votes or falsely like decrypting votes to things that they weren't originally and these folks used a system that sounds the right in theory but in practice they were having problems implementing these cryptographic primitives like commitment schemes and then doing the sorts of things that you need to make the proofs not interactive and this kind of demonstrates like the people at a high level understand what they should be using they know which libraries to pull from but then when they actually like
have to roll it out they don't have an intricate enough understanding of the system to get it right and so that that's what I'm worried about with this new generation of blockchain projects rushing to roll out this research what was the that Swiss voting example we've heard that before but do you do you remember what it was yeah so that was the voting software built by Seidel and the team of researchers that found these bugs were that was liked by Sarah Jamie Lewis yeah that's the stuff that really keeps me up with easier knowledge systems is people who like half know what they're doing trying to roll it out and just getting these like subtle details wrong in that that brings me to a question of how do
you audit a system like this because you know if someone customer comes to you and says okay here's five hundred thousand lines of code for a voting system please make sure that it's secure you know what what's the process that how do you just not say oh yeah that's gonna cost you ten million dollars also because like I can't imagine that the tools that you have right now are necessarily like tuned for this kind of audit yeah yeah so I think we really take like a multi-faceted approach here so we we split the team up based on what the concerns of the folks that were working with are so usually we have someone who's just like a knapsack person and can like wreck whatever code you throw
at them like they're just gonna find like gnarly like rust and go bugs that don't really have anything to do with the higher-level system specification so they work on that and then usually especially if there's crypto involved we have someone like me or one of our more academically oriented folks working on kind of like analyzing the crypto spec and the paper and it's sort of triaging that with what's actually written code and then the first system that would the is complicated is a voting system we probably also have someone doing like an architecture and threat model review so of course like you know if you had to
similar in lines of code we're not going to like actually look at all million lines of code but I think that's part of the skill of being an auditor is is being able to like hone in like really quickly on the pieces that are going to be relevant to you and we actually have some tools that help us do that so with rust we have this tool called scenario file which helps you find risky places in rust code bases so you know rust there's like all these nice like type level protections that make sure you can't shoot yourself in the foot in certain ways but you can sort of over rocket fat you can say like oh I'm smarter than the compiler or whatever and like trust me I'm doing the right
thing so you you can insert unsafe code into rust but when you're writing code that calls it you know ton of other libraries it's not always clear where those unsafe calls are happening and so sodaro file helps you drill down into like all of the like dependencies and in places that you're calling that you might not necessarily even like realize that you're calling and help you find the right places in your code to audit so we can use stuff like that as like a guide to help us focus ourselves for like a shorter audit with like a huge codebase it's cool I've sort of been curious about this like it's trail of bits focused on building an army of
auditors or is it focused on building tools so you don't have that army of auditors I feel like it lives between those things yeah I think I'd like to think of us as more of a bunch of like specialized like precision knives than an army and I mean like I think we're all about coming up with like tools that can automate the things that are sort of time consuming but not necessarily like intellectually challenging for people to find so like with like a kid knows a great example of this there fuzzers in general they help you kind of figure out the little places where things might go wrong so that you don't waste time combing through the
entire code base to find that because a machine can do that for you but once you actually get there it requires a lot of expert knowledge to actually figure out what went wrong and then figure out how to fix it and especially with a crypto stuff there aren't really good tools for going hey you like chained together a bunch of cryptographic primitives together in like the wrong way and now all the sudden there's like a padding Oracle here and if someone you know had like query access to that they could like get your secret key like that's just like not a thing that's like automatable right No so I think we want to get people looking at the problems that people can solve and tools looking
at the problems that are automatically detectable let's keep talking about some of the other vulnerabilities that have come out you mentioned actually just earlier in this episode this Z cash and Manero vulnerability I believe there there's in both systems and it was these side-channel attacks so I'll just talk about the Z cash case because it's a little bit easier to understand I think and basically the idea is okay so in Z cash well let's talk about like the life cycle of a Z cash transaction so a user creates some transaction that they want to send out to like the shielded pool so of course in Z cashier you have you have transparent transactions which like anyone can see in just is like Bitcoin
and then you have shielded transactions which are anonymous and so user creates a transaction that they want to send out into the shielded pool and then they prove that this like commitment of their transaction does all the things that C cache says that a transaction should do and then they send that out to the the peer-to-peer network and it kind of distributes itself amongst all the nodes and then each node takes that transaction and it checks to make sure that it's valid and because of the nature of private transactions in C cache the only way for you to know that you've received a transaction is to actually try to
ripped every single transaction that you see there's a little note field on every transaction that if you are the recipient you can decrypt and that allows you to spend the SEC contained in the transaction okay so like that's like this basic set up but what Dan Bonet and a few other people found is is that there are some side channels here so like the actual Zeke a snark itself is invulnerable like that works as expected but here this is like exactly the kind of button that trail of its looks for in audits is like the way that that was being used at a higher level in the protocol opened it up for these weird
attacks that allowed people to D anonymize users so the first one was called the ping attack and the ping attack basically takes advantage of the fact that your wallet which is like what has all your keys and lets you sign and spend transactions and the node which is the part that kind of maintains the current blockchain state and is like validating blocks and transactions those two processes or sorry those two entities are running the same process on your computer so they're not like two different apps they're like the same thing so what happens is is when a node receives a transaction if that
transaction actually belongs to you the wallet that transaction will take longer to process and that's because you've successfully decrypted the note and then you track to make sure that a bunch of other things are like working the right way and so the attack here is okay so if I want to dean atomized a user and I see a node receive a transaction and I want to see if that transaction belongs to the person who runs that node and what I do is I immediately follow it with a ping message and a ping message here is not like a Z cache specific thing that's just like a networking thing and the
node will respond like hey I got your ping whatever when it actually like processes it so if the transaction doesn't belong to the person who received the ping it'll take shorter than if it actually did belong to the person who receives the ping and that's because again these two things are running in the same process when they really shouldn't be so you can think of it as like the thing comes in and has to wait in line behind the transaction and if the transaction doesn't belong to the wallet it'll you know not do all these checks and just kind of zoom out more quickly than if it did it'll get stuck and so the ping will take like milliseconds longer and that's
the tell I guess exactly it's it's so if you can time this stuff you can actually be anonymized people in the Z cash network there's another tech called reject and it's a little bit weaker than ping it's basically like you know maybe online I have some service that I'm running that you can pay in Z cash or Zek and I give the address but I want to remain anonymous I just want to like get this money and like cash it out or whatever for like the service that I'm offering you could go okay I want to actually figure out which node corresponds to that address because then I can like go well if I know the node I might be able to figure out the IP address and then actually find out what like real person runs that service so
what you do is you you pay the address that you wanted to but you actually encode the transaction in a way that it's gonna fail is it some like fail at the parsing level and so you send them the transaction and they're gonna their wallet receives it and they're gonna start trying to decrypt it and then also and they're gonna go wait a second this is like a bogus message and instead of just like silently failing they're actually that error trickles up to the node layer not the wallet layer and then the node sends back this like reject message and so then you know that they actually were able to decrypt your thing
and made it to the part where they have to like fail or whether parsing it and you can you know get their IP address and all that stuff so and this but this this vulnerability that you described it was discovered by Dan Bonet and who else was on that Zamboni Florian trummer and uh actually Kenny Patterson yeah two folks at Stanford and then uh Kenny's it that's as Erick but this in this case this discovery this like this came from academia which is kind of what like this is just interesting because then you see like there's also academic zero knowledge proof teams that are also doing sort of that that bug discovery
this is not like what I'm so used to seeing are the papers where they release like this is you know the new protocol this is our new idea here are the proofs for it but this is actually an attack discovery so like do you see there's like being a combination between like in like industry folks like yourselves and the academics actually doing the same job yeah I think that now more than ever were actually all kind of in the same boat so like Dan Bonet I mean he's obviously this like incredible theoretical cartographer but he's an adviser to a lot of these companies and like Matt green also great theoretical cartographer but also a founding member of Z cash and so now there's this incentive for these academics to work on
problems that before like you know some random attack on some random cryptocurrency isn't necessarily great conference publication but now all the sudden it's really valuable and so I'm glad to see that that incentive structure has sort of shifted from what is like theoretically interesting and will get you a spot at crypto the conference which is very academic to hey let's work on real problems that affect like money held by real people yeah although I don't know its debt is Dan connected to Z cash I actually don't know that he is but yeah I'm not sure I know I I think he's attached to some cryptocurrency company but I can tell you which one yeah and there's also been
a lot of cool stuff kind of looking at so speaking of issues that were the zero knowledge protocol itself is doing the right thing but higher above it on the stack things are failing there also all this like traffic analysis stuff in Z cache and I think that's really interesting and kind of like plays well with this ping reject attack so like obviously there are a lot of users of Z cache and you can't like try to D and itemize all of them you want to actually have like a target and and I think that this traffic analysis stuff helps you pick that so like basically the idea is is well very few Z cash transactions are actually private I
think that's the thing that maybe we don't talk about enough but like it's like one intends ecash transactions are actually shielded so that puts you in this like sort of like Tor situation where because not that many people use it when someone does use it it's like whoa something's going on here and the folks are there's paper based they were like even amongst the transactions that are private like 85% of them or something like that are just from block mining because the Z cache protocol says that all Zeca mined in a block has to go to the shielded pool before it can go out and do things in like the outside world and so if you analyze that traffic
you can basically deduce that like 85% and remember this is only 10% of the total Z cash transactions that happen like 85% of those are just people mining money and immediately pulling them out and so then you're left with this like really small number of transactions that are like legitimate like shielded transactions and once you get there you can start doing stuff like this ping reject stuff where you're like oh who's getting this thing who's getting this thing and the it's sort of all just like coalesce is together to make the network less private than you think but korzy cash did fix the ping reject reject attack but this is the sort of stuff that I worry about with ZK I think
a lot of this type of research and you know I also feel like it happens a lot from the academic side I don't know if it's a recent thing or I've kind of seen it it's always happening to some degree because a lot of people trying to get PhDs and they have to be doing something so they analyze that exists and you know if you just look at Stanford marketing conference there's a ton of academic stuff they're talking about Bitcoin talking about all these deployed systems just looking at their security properties and I know aetherium like all the theorem clients have gotten multiple reports from various universities saying like oh here's a networked discoverability thing network analysis is super common but the
the serious ones are things like here's an eclipse attack if you manage to do this complicated thing then you can potentially like single someone out and make sure that they're not getting any transactions or censor them in some way and yeah yeah there's I feel like that happens a lot but yeah yeah and I honestly I think this is a good thing because well I mean like I mentioned before obviously we want academics to work on problems that affect industry but also like for new grad students having it not be the case that like your first problem is some daunting theoretical piece of research and is like hey why don't you just try and break the security properties of like Z cache for a while like that's a more
tractable problem in some level than like invent a new zero knowledge system that is like faster than all the previous ones like that's like a really scary thing to work on as a PhD student so the best way to learn something and understand something is trying to break it of course of course going back to that question of like why does trail of bits care about zero knowledge proof are you actually working on any particular projects that involves your knowledge research today yeah so we just were awarded a grant from DARPA to do a bunch of zero-knowledge work in this area of like trying to prove that you have an exploit in zero knowledge the program
which is called sieve is much more broad than that it has a lot of different people trying to find different real-world applications of zero knowledge proof beyond blockchain and then sort of a bunch of academics trying to actually improve the speed of these systems but the problem that we're focused on is I have an exploit and I don't want to tell you how that exploit works but I want to prove to you that it's legit and that brings up a whole host of new problems that I think have not really been tackled by the zero-knowledge community so just sort of like stepping back a second most zero knowledge proof systems require you to represent the problem that you're trying to prove as a circuit and it's it's not
just like a circuit like with like wires and stuff this is like basically a graph where each node is either an xor gate or a NAND gate and so these are like really like bare-bones logical operations so what we need to do is convert the notion of being able to exploit a piece of software to this like really like low-level notion of a circuit and that really actually like plays into a lot of the things that trail bits is good at so the way that you do this is you actually build up a model at the circuit level of how a processor works so some folks did this before with the thing called tiny
Ram which is like a toy little so I like stepping back a second your computer like uses a processor and that chip has like a language that it speaks so that's called like it's like assembly language and the one thing like your MacBook Pro or whatever is like it's super complicated right like it's this like advanced piece of technology the we've like spent forever building and modeling that is like really daunting but you could model maybe a like a chip from like the 80s and those are like really simple so these researchers built a model of this and what you could do then and this is a tiny Ram this is tiny room yeah and you can use tiny Ram to prove
in zero knowledge that you executed some program correctly so you can say like we both agree on a program and the hardware that's going to run on and I'm gonna prove to you that I have some secret input that causes the program to end in some state I mean that that's like basically exactly what you want to do for a vulnerability you want say like hey I have some input that's unlike crash the program or let me like hijack how your computers actually like executing the program but the problem with the previous research is is that tiny Ram is not a real machine right a lot of exploits that you see in the wild where people are like all the sudden like able to like execute any
code that they want on your computer or like get all of your data like these really really bad bugs those actually rely on the subtleties of the chip that you're using and the operating system that you're using and so what trail of bits wants to do is go okay link people model these toy processors before but we're gonna model the real deal and we're gonna bring all the tools that we've developed like these binary lifters binary translators and stuff to create models that are efficient for zero knowledge proof systems and I'd like so that idea that the actual project that you work on is this idea of the ability to disclose or to prove a vulnerability in code without disclosing
what it is or where it is or something like this yeah and I I mean the applications of that would be awesome like the idea that you could you could break a system prove to a company that you've broken the system without revealing what that is and I guess then you could actually like get them to pay you or something yeah yeah so I mean like hey look that could also be used really maliciously because then you could say hey I broke your system you don't know how I broke your system and you better pay me or I'm gonna break your system yeah I mean I think that so you know like the dream application of this is like you know we have these bug bounty programs but you could have like a decentralized bug bounty with this you could have like a program that's funded
maybe on the blockchain or something like that and then if I can post a valid sure knowledge proof that I can exploit the software that you have a bounty for I get paid out and then there's no like trust there I don't have to like be like oh I promise I have the bug you've been you got to give me the money first or like oh I'll give you the bumper like like there's this whole like weird back and forth but then there's even I think a more broad use case that I think kind of gets into like consumer protection which is like there are a lot of companies that don't have bug bounties and actually don't want to seriously address vulnerabilities that researchers discover discover in their code and this is kind of a way of protecting consumers by being able to
post a zero knowledge proof that you have an exploit and saying hey I'm not going to tell people how to break this because the company is not going to fix it or it might not even be fixable some companies hard-code their software into like an IOT device and but that way users can know like hey this thing that I'm about to buy this like smart fridge or whatever has a lot of zero knowledge proof that exploits like whatever website and maybe that's not the smartest thing to buy but the people that already have them aren't putting risk by this like bug disclosure I think we actually in our conversation with Isaac Meckler from oh one labs a few
weeks ago we talked about this like zero knowledge proof for compliance or zero knowledge proof for verification and I remember he had an example sort of along the lines of this where you would be able to prove that a certain kind of code was used in something without disclosing what that code was but here it's more things are broken I can prove that they're broken but I won't endanger those that have this on their computer but I will give people an option to make a better decision this is right or you know if the company is decide to fix it um you could actually then rerun the zero knowledge proof to show that the exploit can't happen so you can have like on
zero knowledge proof that the exploit exists and then if they fix it a zero knowledge proof that they fixed it so like that to me is really exciting and hopefully kind of like can improve what I think is like the not-so-great state of vulnerability disclosure and protecting people from you know bugs and software the DARPA project is bigger than just what trail of bits is working the news are there are there like resources we can find on this like is there some documentation anywhere not yet okay right now like like I know who else is on the project and I kind of know what they're doing but I can't say because they haven't like announced it um how about we round out on the topic of ZK what do you see is the future for
this what will your future involvement being this curious to hear your opinions yeah so I think that like I've been saying I think that there are a lot of people in this space who you know are total like experts at ZK and their belief systems that like work great and they understand how to fix them when things go wrong but we're seeing people who are not like expert cryptographers trying to use this technology and that's what we want right we want people to use ZK and to get the privacy guarantees that it provides so I think that where we need to go you know on top of like improving all the efficiency and that stuff is really building libraries that
are usable for people who don't know much about zero knowledge so that people like like voting companies like blockchain companies that aren't you know staffed with a bunch of like Stanford phd's so that they can use this stuff too and I think that this is sort of like a broader emphasis that I'd like to see cryptographic engineers kind of like focus on which is yeah building libraries for people who aren't experts and I think that that gets into some stuff that we aren't necessarily good at intrinsically as math people like we need to build API is that our misuse resistant and we need to think about users in a way that we haven't
necessarily thought about before and not just like expose every function to the user and say like oh like you just figure out how to use this like whatever you know we need to like really help these people out because that's our job as experts to not just sort of say like hey you know just like throw them in the deep end and hope that they don't drown well thank you so much for sharing all of this with us Ben yeah thanks for having me to our listeners thanks for listening thanks for listening [Music]