This is epicenter episode 346 with guest Dan Guido.
Hi, welcome to epicenter. My name is Sebastian quechua.
Today, our guest is Dan Guido, he's a CEO of trail of bits
there, a software security firm that has been around since 2012,
and they work quite a bit in the blockchain space, but not only.
They also do work in the sort of broader software security space.
They work for government institutions as well in the US.
They're very good at. I mean, one of the things that I
Love About Your Love B is that they're great communicator.
So they have an amazing blog that just captures a lot of the
work that they do. And so if you want to learn
about software security, I think like their blog is a great place
to start. They also have a Publications
repository on their GitHub where they publish all their security
Audits and also all the research that they're doing.
So they're really sort of a great thought leader in the
space of blockchain security. Research.
And I've been want to get down on the podcast since about a
year. Now, I mean, they were
previously a sponsor of the show and we're supposed to do this
interview at ECC and Paris. Obviously, I didn't happen
because Den didn't come over, so it was glad to finally get them
on the podcast and it was really great conversation Federica.
And I did this one together and Dan is just so articulate and
explains things with lots of clarity.
Also, you know, in a way that for us software, security
Lehman's, Are able to understand.
So after the interview for a taken and I went on for an extra
10 minutes talking about, you know, our thoughts and what we
learned from the interview. Also, describing her experience
with security audits. Obviously, you working at
gnosis, she's had to deal with that quite a bit and we also
discuss the potential for more Gatekeepers and the DAP
ecosystem in order to create a safer space, for people, to
invest their money and used apps that have been vetted by
Gatekeepers. So, You want to hear that
conversation? Please subscribe to epicenter
premium. You can do.
So it, premium epicenter, dot TV, that gives you access to
host, debriefs, where we go on for an extra 10 to 20 minutes.
Share our own thoughts about the interview, also Roundtable
discussions and bonus content that will put out from time to
time. So with that, here is our
interview with Dan Guido We're here with Dan Guido then.
Thanks for joining us today. Thanks for having me actually.
We've been wanting to get you on the podcast for some time.
Actually, we were supposed to talk at ECC and you didn't make
it. I think that was probably a wise
decision of, you'd not to fly over.
Yeah. Turns out the professional risk
manager knows how to avoid certain downsides, thanks for
joining us. I mean, you know, we've been
talking for quite some time also because our listeners, remember
that trilobites was a sponsor of the podcast about a year ago and
So it was great to get to talk to you then also and kind of get
into this topic of security. And so this is an episode that
I've been wanting to do for a long time because we obviously
talked about security, a lot on the podcast but never really
done any episodes that focus on security and there's a lot of
things here I think that will learn.
And also maybe be surprised about like, you know, some
misconceptions and things like that that I'd like to get into.
So yeah, tell us a bit about your background and how you came
about founding trailer pets. So I've been doing security
stuff for the better part of my adult life started.
Probably when I was about 13 14 breaking into my school
computers like one does as one does luckily escaped being
severely punished for that but I ended up going to college for a
concentration program in cyber security.
It was called Polytechnic University when I went there but
now it's the NYU tanton School of Engineering and they have one
of these NS a center of excellence programs that teach
kids a formalized education in cybersecurity.
I think that Well that are a little bit younger than me, have
a lot more formalized education and people that are a little bit
older than me, don't they learned from their peers?
They learned in kind of like a master Apprentice kind of set up
so I'm right on the cusp of that.
So I have a formal background in computer science and computer
security, and this is the only field that I've ever been
interested in working in. So I've worked at the FED
Reserve doing incident response helping prevent people hacking
into the currency. Reserve, the United States.
I've been a consultant Sultan tat isec Partners now, NCC
group. So I was, I sick Partners before
there were required. Help start their office in the,
on the East Coast worked with dozens of technology companies
across the globe. But I was pretty frustrated that
it seemed like an unending treadmill that you kind of go
back to clients year after year. And there's always the same bugs
and they don't really internalize the information that
you give them. I thought that there was some
improvement that we could make and I wanted to make fundamental
improvements to the whole field. So I found a trail It's with two
friends of mine back in 2012 to fundamentally Advance the
science of computer science and computer security.
I think we've by and large succeeded at doing that and very
small ways. You know, the company started as
a DARPA contractor, we worked on for year-long research, programs
and automated program analysis and advanced cryptography.
And then from there, we branched out to help provide those
advances to commercial firms and now to blockchain firms.
So that's the, I guess the medium-length overview of where
I came. Came from and what we're doing
now. Tell us about how you got
interested in blockchain as a cryptographic field.
Because I mean basically you found a trade-off B in 2012 and
obviously then it was still pretty new.
So what exactly spoke to you about it?
Yeah, a couple of things, I think it was really driven by
employee interest. There about two or three people
in the company that were just really enamored with blockchain
has technology because it was a green field not necessarily
because it was anything that you could do with blockchain, but
because the field was in it, Infancy was a chance to start
over it was there were no security tools.
There was no security knowledge, people were building their own,
programming languages, building their own compilers, the
execution environment, looked a little bit different.
So there was this huge gap of knowledge that we could rush in
to fill and create things that were correct from the first
step. So, back about three to four
years ago, we had a couple people dabbling in that area of
technology and what we contributed was a symbolic
verifier. That was our very first thing,
we didn't raise our hands and say, hey Will audit your code
for you. We're Engineers.
So we set up a little unit of people that wrote symbolic
capable etherium virtual machine into a tool that we have called
Manticore. And then once we were able to do
that, we realize that hey this is actually kind of valuable and
people would love to work with us to improve their own
security. So because we'd already mastered
the field through that activity that research activity.
That's how we started offering services for blockchain.
How much of your client base today is blockchain base because
you told us just before we started the coil, that we should
update our versions of Zoom because you just release the
fixed. So, how much is basically in the
web tool where and how much is in the web three word of your
company clients? Trail bitches.
A company is split into a bunch of different pieces.
We have a research team that continues to work with DARPA,
the National Science Foundation Department of Defense, like
various other agencies of the US government to fund long-term
research. That's probably about 10 to 15
people, depending on how you count.
We have an engineering team. So, because we have these expert
software developers that can apply research and make real
software with that research. We also have an extraordinarily
capable team of people that you can hire to build software for
you doesn't need to include research.
It just needs to be something that you need.
Usually, it's security software, sometimes it's high Assurance
software, things like cryptographic libraries.
So our engineering team is about another, you know, 10 or 15
people and then we have an assurance team.
And our Assurance team is who the blockchain industry.
Typically collaborates with their people that are
specialized at taking owner door, taking a look at other
peoples code and helping identify hotspots weaknesses and
specific security risks inside them, and that Team Works across
the defense Tech and finance space.
So we've reviewed things like autonomous drones satellites
cryptographic protocols for satellites.
We've looked at embedded firmwares.
Self encrypting hard drives and most famously right now.
We're working. Zoom, when people have a need to
really rapidly, get to the root of difficult problems,
especially ones that involve compiled code, and cryptography,
trailer, b is among the top choices for that assistance.
So blockchain right now I'd say takes up about like a third of
the company's business, maybe a little bit less, maybe 20%.
But you know, we have a really healthy Diversified business
when we work across a lot of areas of technology and I try to
shuffle kind of things that we've learned and the tools.
We've built and the talent that we've acquired across all those
different Industries which is what makes us kind of a unique
company in the blockchain security space.
So it's interesting that you work with zoom because they just
bought key base and brought on that entire team of
cryptographer. So you're saying that they
bought key base, they got all these cryptographers but they
also need to get extra cryptography.
Experts in addition to that team, Oh, yeah, I mean, look,
they're code base has been evolving over the better part of
10 years. It's got hundreds of thousands,
millions of lines of code. That's cross-platform with Linux
Mac Windows. They even have a Blackberry
client, like, there's server infrastructure out there.
It's a custom Network protocol, custom cryptographic protocol.
There is just a voluminous amount of stuff there and when
you have that level of scrutiny on you as a firm like zoom in,
you know, No, today's environment.
You need to really apply a lot of effort to uncover flaws
before other people, find them and to keep your clients safe as
best as possible. So we've done a really detailed
review of all the client software, other firms were
brought in to. Look at all the server software,
but a really key part of our responsibility was to.
Look at the existing implementation of end-to-end
cryptography. We've helped them kind of
analyze, the current state figure out where it's hooked
into the client, how it exactly Works.
What the kind of cryptographic properties of it art.
A. And then the key base folks are
working a lot more on what it should be tomorrow.
So, a lot of the initial value that the key base folks,
provided is a white paper, that's now, published up on
GitHub that. I think a lot of people have
read and that's great and that proves kind of like where things
should go. But it's going to take weeks
months, you know, possibly even longer to get there and in the
meantime you need to make sure that the software you've got
today is safe, which is what I'm working on.
Is that in your career? You've been working on on
security-related stuff since you were in your early.
Teens, how has software security changed the most in your view?
What's been the most like, fundamental shift between say
how software security was looked upon and conducted, like, maybe
like the early 2000s to now, I'm kind of jaded.
I don't think it's changed really at all.
There's been a lot of movement between programming languages
like everyone jumped on the node.js bandwagon at some point
and then everybody jumps on the rust bandwagon and everybody
jumps on the Swift bandwagon and its history repeating itself to
a great extent. Like we saw this with the iPhone
and Android, right in the first versions that came out, they
didn't really apply any of the best practices or Lessons
Learned of the previous generation of software.
That weren't sandbox. They weren't hardened with
compiler protections. And they didn't have a great
user experience like there. Just wasn't a lot there and some
of those early mobile phones for some of the easiest software to
hack on the planet. But now, you know, they took all
their punches and they had to learn from failing, which is
kind of unfortunate. And now, an iPhone is kind of
the most secure consumer device that you can buy.
There's not a single device that I could go to Best Buy and say,
is more secure than a, than an iPhone.
And I think that's kind of the process that a lot of fields of
Technology go through for better for worse.
So really, Means as a security professional is that you've got
to learn this kind of fundamental underpinning.
There's a lot of like foundational security knowledge
that you need, but the technology that you work with
from day to day over the course of your career, is going to
shift pretty rapidly as things. Get to be less mature, more
mature, All right, so it's more about technology changes.
So much as it is about changes to, like, how you secure
software or Hardware, the risks are the same or fundamentally
the same, but the tools that people are building to use the
infrastructure are changing On any given day, our Assurance
team is working with people that write code and, you know, Java
PHP, Ruby rust rails, Django various see Frameworks, or C++
Frameworks and blockchain software and like everything
under the sun. And everybody just kind of
expects you to know that stuff and really like learning how to
code in C or learning how to code.
And rust is not the hard part. People challenged us to do that
all the time which is why the whole block chain thing.
Also comes kind of naturally to us like if you're a good
security, but then you're going to be able to figure out exactly
what's going wrong in a smart contract.
To the most important part is the security expertise, which is
something that you have to learn and grow over, you know, a
decade or a lifetime, or a full career If you look at blockchain
technology and smart contract, technology are their unique
design and security challenges in these protocols.
The unique security challenge is really that the tools that
people are using to build blockchain software are awful,
what changes between different languages and Frameworks is that
sometimes certain tools have a lot more foot guns in them than
others. So it's a lot easier to write
security vulnerabilities and PHP than it is to write security
vulnerabilities and rust because there's a lot of safety to fall
back on in terms of the language and the compilers and the
development Frameworks. But with solidity, especially
not just a little, but many other blockchain.
Languages, they've managed to reinvent the entire history of
software security flaws and make it the developer's
responsibility to be aware of all of them.
So, really the key difference here is that developers are not
getting any help at all from the tools, in the language that
they're using to develop blockchain software, which makes
the after-the-fact Assurance that's provided by companies
like mine critical. Now, on the other hand, what
blockchain has that's going for it.
That other languages don't is that smart contracts tend to be
a lot more testable code than Traditional code.
It's really easy for me to throw it into an emulator and for me
to send inputs to Any Given function and to evaluate what
the impact is on a really simplistic State machine but on
regular software like if I want to set up a fuzz test client for
Google Chrome or something like that, there's a lot of global
mutable State. There's a lot of libraries that
change their behavior depending on what operating system you're
running on or what specific configuration of your operating
system you have. Have.
That's why I like, you know, when your parents call you and
you're, you know, some software on their computer crashed.
You have no idea how to debug it because you have to be aware of
every single setting on their entire computer.
All the other software that's installed alongside all the
shared libraries that are there. But on the blockchain,
everything runs on the same Block Chain.
So if I have a copy of the blockchain and you have a copy
of the blockchain, then it means that we're testing, we're
running the same code, so that's actually made things a lot
easier for blockchain software. Despite the fact that there's
incredible insecure In the tools that you're using to build it.
Can you give us an idea of what a mature to link it should look
like? So basically if you look at like
languages that have been around for a while like rust for
instance, what ideally would we have in terms of tools in order
to be able to have the same trust in the tooling as you do
in traditional systems? Yeah.
So it's not a question of third-party tools.
It's more question of the language in the compiler itself,
right? Like everybody's familiar with
the fact that solidity can't seem to make it more than one
release without a critical flaw. Everybody's also familiar with
the fact that tools like Slither, you know, one of my own
static analyzers from trailer, b have to watch out for 90
specific flaws or that the use of integers is inherently unsafe
inside solidity. And you need a third party
Library like safe math in order to catch you when you fall.
So the kinds of things that make a language safe.
Our the avoidance of those issues that, you know, I
shouldn't have to worry about the order of operations because
the order of operation should be the same as every other language
that I use. They shouldn't be different like
they are in solidity. That's a big part of the
language design. Their just should not be so many
foot guns, there should be right now.
I think that there's kind of a pressure to make solidity more
feature full to add additional, kind of things to it, that help
you develop code. And as a security engineer, I'd
pull back, I would want to make something that looks like
solidity - - not. So, Aditi plus plus I want
something that's a little bit more simplistic that fits 99% of
people's use cases, but that 100% of those potential uses are
safe and that it's much, much harder to screw up.
That's why you see, you know, rust things like memory safety.
Type safety. It takes the universe of things
that could go wrong and limits it.
We're now, I just have to worry about logical flaws.
That's much better other things that but, you know, tools like
rust have that are really nice is that it specifically declares
when you're doing something that's unsafe.
These. He's like I as a security
engineer, the most precious resource I have is time when I'm
looking at a piece of code, it might be larger than the amount
of time that I have to fully review.
All of it end to end if I could specifically identify like, hey,
this part of the code base is insecure because the developer
told me so because the compiler force them to then, I know where
to spend my review, effort to get the most bang for my buck.
So rust again, is really good. There.
It helps identify ahead of time. What you're doing is unsafe All
those are features and capabilities that solidity and
particular lakhs. But that also aren't present in
most other smart contract language has to kind of
summarize here for the lemons in the audience.
What you're saying is that social stability has sort of
inherent issues that make it unsafe because as a developer
you're able to do things instability that in other
languages would just be impossible to get wrong or the
compiler or your tooling what alert you that what you're
doing. Is unsafe.
Yeah, absolutely. We actually have a whole talk
about this. We can have a conference
presentation, called anatomy of an unsafe smart contract.
Programming language. It's up on the trail of its
YouTube, it's really entertaining.
It's got tons of great graphics and a little bit of some movies
and a jingle in the middle of it.
So if you're interested in looking at it further that dives
into the specifics of why we think solidity is a poor choice
that we're kind of stuck with now for developing smart
contracts. But again, luckily, what we've
proven is that over time Is possible to build secure
solidity, smart contracts because they're more testable
because it's easier to do. After the fact, verification of
them means that you can still produce secure code and possibly
even more secure code than if the compiler tools helped you.
But it's not a question of either or like, obviously, why
not both right. You shouldn't have one set of
tools undercut, you and then you're testing tools, lift you
back up. And that's kind of the struggle
that I always have in the, in the blockchain community is, I
would love to work on the compiler tools.
I would love to To improve them. And the things that we've done
with slither specifically to formally kind of model things
like the you'll parser and the AST for solidity are things.
That should be adopted Upstream. We have all of these testing
tools and everything that allow us to in the end essentially,
right secure smart contracts, right?
Because we're able to catch all these bugs and were able to fix
all these little inherent issues with solidity.
Does this introduce other Is or other security vulnerabilities
that perhaps another language like rust or more mature has
language like C++ wouldn't encounter like what are some of
the negative effects? Perhaps of, like having a
language that is inherently insecure by its construction
even if we can go in and fix all the bugs after the fact, I mean
it just puts a lot more cost into the process of delivering
good software. So you know, a lot of blockchain
firms don't go through a 50 million dollar Ico, a lot of
blockchain firms. Have difficulty hiring a
security engineer to work full-time on their team and then
my resources are always stretched.
Then, people are complaining all the time about how I try to hire
Trail bits. And they told me that they
couldn't start until a month from now, or two months from
now, or whatever it is. And I need them tomorrow.
And that's because there's only like, you know, two dozen people
on my entire team that are trying to hold up the entire
What it means to have good compiler tools, is it means that
security is easier. It means that more people can
produce more secure code without expert help so that entire gap
of the poor tools and poor language that the etherium
community currently end. Others are suffering under slows
down the whole field. It has a systemic effect on the
ability of teams to ship software.
It's really important to solve and I'm surprised that more
people haven't been angry about that.
And they are about angry about my project lead time or
something. It's more systemic risk, its
ecosystem risk rather than individual project risk you'd
say yeah. I mean this specific design of
solidity is what handed teams like mine, kind of the the power
and position that we have in the community.
I'm self-interested of course, like it's great that people turn
to me for help and everything but I would love it.
If people didn't like ultimately I like to try and put myself out
of a job that's why I produce tools like Slither and why I
released them open source and let people use them without
talking to me is, I would like to have to try harder.
And from day to day, and I want people to give me new challenges
to solve, but the position that we're in is that there's just
this influx of people that continue to try and write new
smart contracts every day. And they fall into the exact
same traps as the last person and that's kind of a poor State
of Affairs. Can you just briefly explain
what it's leather and what it does and how it helps.
People save time. I guess trilobites has a suite
of etherium. Security tools, Slither is kind
of the first layer of them, that's what we use.
Where it's the lowest effort highest value at the other end.
You can just press the big red button and it tells you bugs
that are in your code. The way that it works is when
you compile solidity code with the solidity compiler, it
produces an AST and Abstract syntax tree, and intermediate
representation of some sort prior to creating by code that
goes in the blockchain. So we take that AST, parse it
and we parse it into something called Static single assignment
form SSA form. And then using SSA form, we use
a whole bunch of stuff from compiler Theory to kind of
process it and analyze it as well as Traverse it for the
security issues that we know how to find.
So every single project that we do where we review a client's
code, we have a process afterward where we collect what
we learned. If we found a new bugged like a
class of bug or some That's prevalent within the clients.
Codebase, we try to encode that programmatically into what's
called a detector inside Slither and then in the future Slither
should be capable of finding bugs of that type.
The goal for trail of B is I never want to find the same book
twice. I only ever want to find a bug
once and slithers the primary tool that lets us do that in
very layman's terms like a spell checker your for your code, sort
of thing, kind of, but way more advanced than that, because this
thing can parse like it can understand English grammar.
Yeah, it's primarily for your good.
Yeah. Maybe do you think solidity is
beyond fixing? Should we just scrap it and try
a new language, or do you think we can turn this around?
And what are you thoughts about Viper?
So I think vipers a great Improvement.
I do think it's possible to fix solidity.
It needs somebody to come in with a really strong vision of.
Here's where we need to be. And here's why and right now,
the kind of iterative, you know baby steps kind of approach that
I see of each incremental. Kind of Marching In The Same
Direction, isn't really trending.
The direction that I'd like to see it go I think it needs
fundamentally a really strong leader to come in and say this
is hurting our entire Community. It's hurting our ability to ship
software. It's making people lose money
and it makes us too dependent on security Engineers.
We have to fix this problem. Do you think it would be wise
for aetherium just to say, like, adopt rust or something like
that? I mean, where would that put too
much of a learning tax? Say, on developers, to have to
learn this skill of complex language, there's pros and cons,
right? Like as a security engineer, I
know that I'm not the most important person in the room,
like the most important person in the room is usually the
product manager because you don't have a product unless you
have users, unless you have a market unless you're providing
value to those users and you actually do something that care
about a perfectly secure. No one uses this valueless
trying to say that everybody should stop development pick up
rust over the next six months is, you know, it would hurt a
lot of people. It would you wouldn't be able to
ship software, you lose all your users, there'd be a lot of
developers to fall off a lot of companies to fall over.
So the kind of hard break, I don't think is really in the
realm of possibility, but I do think it's possible to get
incrementally better, and it's possible to have other
Alternatives, like Viper. So, you know, a lot of the
criticism lately that I've seen a Viper, I don't think is On
Target, The Viper compiler. You know, while it's suffered a
couple of setbacks now and then people find bugs in it.
We found bugs in it, right. Somebody paid us to do a Viper
Security review, or we work for computable.
They had their entire code base written Viper, and we found a
compiler bug during the project, but just because we found one
issue doesn't mean the whole thing is fundamentally unsafe.
I think from architectural like high-level perspective, there's
a lot of things about Viper that I like We've talked a lot about
formally verified languages on this podcast and lots of
blockchains have implemented this programming Paradigm.
I think I can kind of explain what a formally verified
languages but I'd like for you to perhaps try to do better
explanation and one of the things I think people think when
they think formally verified language is like no bugs or it's
basically free of being able to be hacked, right?
And I think that's like a misconception, obviously, can
you explain what a firm believer?
Foreign languages and what people are getting wrong about
it. When it comes to security, Yeah,
sure. See if only verify code that you
wrote, right? And the way that you do that is
you express some security properties about it and then you
prove them, you use a tool to prove them and there's two main
components here, there's what properties you express, and then
there's how you prove them, which creates this widespread
difference in what it means to be formally verified.
Like, if I write a smart contract and it's two thousand
lines of code, and I write a single security property.
Is it formally verified? Yes or no.
So like trying to say the code is formally verified or not as a
binary. It tells me that you don't know
what you're talking about. What's really at issue, here is
what the properties are, the Fidelity of them, like how
accurately they explain the critical functionality of the
code. And then the method that you
used to prove them, because you could prove a security property
with a unit test, but a unit test might only test one,
positive interaction in the contract.
It might not test all the potential negative interactions
all the things that you didn't think about.
So then you start getting into things like fuzz testing where
that's a test case generator so you can use a test Generator to
probabilistically, generate a wide variety of potential
inputs. That might break a security
property and that's good. But then is that the same thing
as a symbolically verified security property or an abstract
interpreted security property. So, all these things kind of
change the Fidelity of the security properties that you've
defined, we're at a very low level, you know, maybe unit test
might be really good place to start, but then over time you
prove that security property with stronger and stronger
methods. That are harder to kind of
Escape gaps in coverage. That's one take on formally
verified software. Another is we published an
academic study trail of bits went back and look through two
years of etherium Security reviews that we had performed.
And we split all the bugs we found into one of two categories
bugs that you can find automatically with a verifier or
other tool and bugs. You can bugs that require a
human brain and we didn't talk about the state of Current
tools, we did that. We actually just talked to
theoretically like, is it possible to build a tool that
finds this bug? And what we found is that 50% of
the bugs that we find could never be found by an automated
tool. Now, there's some gaps in that,
there's, there's some really nice things that came out of
that paper. One thing that came out is that
for the highest risk bugs for the bugs that were the highest
severity and the easiest to exploit. 80% of them can be
found by automated tools. So if you're effectively using
automated tools, including verification tool, Rules.
Then you are wiping away 80% of the highest risk issues that
could show up in your projects which is a great result.
There's a lot here about formally verified software that
I think people don't understand. So when you when you say you
split these bugs up into two categories, the ones that can be
automatically found in the ones that couldn't.
So if this just by like some sort of program that kind of
checks against known bugs is there like some machine learning
artificial Intelligence involved in.
We hand reviewed every single bug.
We had a, we had a team of smart people sit down and think about
every single bug. We found for two years and tried
to imagine in their head. If you know a supercomputer, you
know, alien came down from the future.
And provided us with the perfect tools in the universe to find
software security bugs, would it be possible to find this bug
with that tool? And for 50%?
The answer was no. So you still To have a smart
human. How do you determine that
though? Yeah, exactly.
I have exactly the same question if you kind of have computer and
you don't know that it's a human inside, right away.
See how is that different from a?
Just a super smart computer that you can say, look, you really
need a human to identify this bug.
No computer could ever do it on its own well.
So a lot of it means that you have to think about, okay?
So here's how you talk about it. There's a lot of bugs that are
generic to the programming language, like Access Control
issues. It's a problem if If you forget
to control the access to some kind of function that lets you
upgrade the contract, right? Or kill, kill the contract.
That is a fundamental invariant that you can express for the
entire programming language in all programs written in it.
On the other hand, there are security properties that you
might need to Define that are specific to your contract.
There's something that you are trying to do, and the only way
for me to tell that this is a bug, or this is not a bug, is if
Have a smart developer tell me that that's what their intention
was. But if you have a specification
of some sort that specifies that then you could presumably also
have a computer. I mean I guess that's maybe what
formally verified languages. A lot of you do is you create
kind of this like this framework or the spec in the traditional
software sense, like let's say, so the reason why fathers are
really prevalent inside of like compiled code C and C++ is that
I know that when I get a crash that that's going to be a bug.
Right software should never crash.
So therefore, if I find a crash it is a bug on the other hand.
If I have a smart contract and I managed to, you know, transfer
some money to somebody out on the blockchain.
Is that a bug or not a bug? I don't know because that might
have been my intention to do it. So you really need some element
of guidance that you typically don't need for traditional
software. The other thing here is that a
lot of these vulnerabilities, there's just like high level
logic involved, there's high level thinking.
But a machine is not going to discover on its own and that it
would be incapable of kind of creating on its own.
But there's a blog post that summarizes.
It called 246 findings from a smart contract Audits and
executive summary and we will link to that in the show notes.
Great. We've kind of jumped in the deep
end here, so maybe maybe that's go back to square one.
So basically say I've built a project on E, theorem say some
type of decks and that's a team of developers on the projects.
And we're making the leap to men it.
But of course, we think we should get this audited in.
This is probably one of the times when people call you and
say oh, why can't we start tomorrow?
But you know, like only 2 months from now.
So we call you and what do you guys do?
So they see what us the journey look like first off.
You know, I think there's a misconception that people should
hire security firms. The second that they finish
their software. Usually, that's way too late
for. Exactly the reasons that we just
got done discussing a lot of your Depends on the ability of
the developers to express, what their intentions are.
What are they trying to do with the software?
Did you write a spec for it? And then, did you write the
minimum amount of code necessary to actually Implement that spec?
Because complexity breeds and security and the more
unnecessary parts of your code that you write the more bugs
that you're going to have so engaging with the security
professional early is really critical.
We really like it. When people engage with us at
the design stage, we can talk through different implementation
strategies. That might reduce the foot guns
that they leave in the code base.
The areas where they're likely to have bugs that ends up making
the after-the-fact review the final stamp.
You know, the final test before it goes into the Thunderdome on
the blockchain, it makes that process a lot easier.
So when we do actually get hired for a security review, a lot of
what we end up trying to do is reverse engineer the intentions
of the development team because the developers don't always know
what they are. So it involves a lot of
communication, a lot of, you know, back and forth
conversation about Hey, what were you trying to do here?
What is the intention of the system?
And then will encode that into a spec for the team that we work
with or write out the security properties ourselves will prove
them with property, testing fuzzers, like Echidna or will
prove them with a symbolic verifier, like Manticore.
And in addition to that, we'll find those.
Generic language level invariance, things like a lack
of access control, or integer overflows or re-entrance E and
that kind of stuff that might sink your ship in different ways
that process continues. For, as many weeks of the weeks
of the review that we have and then what we do at the end, we
sort of doing this a couple months ago, about two months
ago, is now, we also include a code maturity evaluation because
security isn't really like, okay, great, you're done now,
like somebody looked at your code, all the bugs are gone,
that's not how it works. Because you created that code,
you could have hidden any number of potential issues in there.
And really what we're doing is assisting you that's why I call
it a Security review, not a security audit, right?
This isn't like accounting or I can tell you Everything is like
you know all the dollars are properly accounted for and
therefore you're not committing fraud.
This is more of a probabilistic check where hey, you know I
noticed you're doing some things that aren't so great.
It's like you know, when I used to play baseball as a kid, I
videotape myself swinging the bat and then watch it.
And I'd have somebody else that new a lot better.
How to play baseball? Take a look at it and say, oh,
you need to step like this and then you'll connect with the
ball better. That's kind of what a Security
Professionals doing. They're trying to tune you up.
So, you produce the most secure code And so, the code maturity
evaluations, give you a long-term view as to where you
are in the process. Like, what is the state, what is
the maturity of your testing and verification?
What are the maturity of your access controls?
What is the maturity of your use of assembly?
And how is that going to cause or not?
Cause issues in the future? Because this doesn't really end
after you release. Usually, you've got a version to
that's cooking, or there might just be advances in the field or
the Block Chain itself could change underneath you, you know,
who knows what the etherium foundation.
I was going to push in there. You know, next biannual hard
Fork that might eliminate all the kinds of security
protections that you put in place or or the next person to
invent flash loans that all of a sudden takes the security margin
that you had for interacting with the all your oracle's and
drops it to the floor. What for exactly these reasons.
Basically, what we see more and more upgradeable contracts,
right? So upgradeable smart contracts,
but they come with them. Their own pitfalls.
Can you talk about that? Yeah, so upgradeable contracts
are really interesting case study because there, another
example, where the solidity language shoots itself in the
foot, like, in order to do upgradable contracts, you have
to, you have to use a substantial amount of low-level
solidity to get them done. And the fact of the matter is
that we've identified 17 unique ways that upgradeable contracts
can fail and either lock your contract or lose everyone's data
or be exploitable. After you put them on the
blockchain and It's really not as simple as people think.
Not only that, but it creates risk because now you're, you
have to handle private keys on your corporate.
It like, you know, you've got a network somewhere.
You've got a computer somewhere. That's got some keys that let
you manipulate the functionality of a smart contract on the
blockchain, which is massively fraught with risk for a number
of reasons. Doesn't that defy, the whole
point of a blockchain, it does. It really does.
So I trilobites were not too big fans of upgradeable contracts.
We understand the need for them, like it's Critical that people
have you know contracts that can pause when they're having a
security issue. It's critical that people can
recover from an incident when they experienced one.
But the methods that people use for upgradeable contracts today
tend to be inherently unsafe again Slither is a tool that
enables us to only find bugs once or only have to find bugs
ones and we've encoded all those strategies for, you know,
accidentally failing threatened, upgrade will contract correctly
into Slither. So it checks for all those 17
cases of failure, Doesn't mean that's exhaustive.
There's probably more and there's a lot of other ways that
can go wrong. Like, you can just get hacked
and lose your keys, which is another thing that we consult on
like how to use an HSM to store them like a professional.
But upgradeable contracts tend to carry a lot of risk with
them. So, instead we try to promote
the use of contract migration, which is just burning the whole
house down. When you've got a contract or
token or whatever out there on the blockchain, you can save all
the data and roll it over to a brand new car.
I tracked that presents a lot of issues.
Since clearly you have to notify people that might be using your
old code to use your new code. Also has implications that defy
space since there might be some, you know, defy app that's
sitting up there on the blockchain that's hard-coded to
think that you're at a certain address but now you're not how
do you fix that? So you know, there's not
challenges to it but it's inherently safer since there's a
lot less moving Parts, it's cleaner.
I also think it's more honest I totally see that.
I mean, that's that's pros and cons, right?
So I totally see that. It's probably the most secure
way or it's definitely the most secure way.
Then the question is, do you kind of leave it up there and
just tell people to migrate and then, basically, you have the
problem of split liquidity and different versions.
And you can't do that too often and it's kind of fraud, both
ways. So, when we think about Security
in blockchain technology, we almost invariably go straight to
Smart contract failures that There's also plenty of, you
know, like front-end and back-end vulnerabilities, that
we pay not as close of a mine too and so they're often
overlooked. So for instance, with what
happened with Luke, bring a couple of months ago, I don't
know whether you remember that. I don't.
It was about the way that hash was stored somewhere and there
was like a limited number of hashes that they were actually
using. They were they were, they were
generating hashes and 32-bit space.
That sounds bad. Do you think we pay too little
attention to the things that happen around the smart
contract? So, basically, the front-end and
back-end infrastructure brother, because everyone goes straight
to the smart contract, right? And people do smart contract
audits, but I know a few of fewer companies who actually do
complete front and back-end audits, just because it's an
expensive thing to do, right? Yeah, I mean I think there's
some properties about smart contracts that make them a
little bit more. Like I think it's correct that
you focus on them for the first line of your Security review.
They're fully exposed to the public.
Anybody can go read and run the code which is really unique.
Right? If you have like server
infrastructure up in the cloud somewhere, I can easily grab the
source code to that and start messing with it.
I have to I have to just poke a black box which is a
fundamentally different kind of problem to solve on the other
hand the information you know, quote unquote.
Formation that you steal from a smart contract is inherently
financially valuable. So when you think about this,
from an attackers perspective, what they love, what they
ultimately usually want to do is make money, sometimes they want
to get Fame, sometimes they just want to, harass people and
troll, but for the most part, they want to make money.
It's much easier to make money, hacking a smart contract than it
is to hack a server somewhere on the internet because once you
hack the server, usually, that's a pivot point axis, something
else that does have Financial value.
So there's more Steps involved in cashing out, right?
So for those reasons, it's definitely appropriate to focus
on the smart contract, part first, but, yeah, by no means
don't stop there. You absolutely need to think
through the entire perspective because again, how secure is
your smart contract. If you publish the keys for
upgrading it on the internet, right?
If you're just throwing them on your personal laptop and that
person laptop attacked then. So does the smart contract and
every single piece of data on it.
So, yeah, depending on You trust.
And the way that you designed your system, the security of
your oracle's, the security of cloud infrastructure, the
security of your mobile applications, the security of
your authentication system can all play a role in.
Ultimately, the security of your product, which is what you need
to think about. You need to think about, is this
product, doing the things that my clients expect it to or am I
going to unintentionally lose all their body or
unintentionally, do something that they don't expect, right?
And and that's a larger problem than simply is your smart
contract safe. For a lot of clients.
We've actually started doing threat models people in the
Block Chain. Space haven't been to up on it
because they're more like interested in the really quick.
Kind of like, you know, rush out to production.
I know what I need and, you know, I'm really kind of
ego-driven secure Tech Master of the Universe and not a lot of
people stop and think, like, okay, well, what don't I know
and what should the interactions be between the systems that I've
designed and what are the risks that I need to mitigate against?
So, for a lot of people in more mature Fields, we've been doing
threat models, for instance, election systems voting systems,
not closely related to governance systems but not quite
for those. You know, you could throw
security at the wall and see what sticks you could just go
and say hey I've got 10 code bases, I'm going to have
somebody do an application Security review.
I'm going to make sure that I can't crash.
But really what you want to understand is how easy is it for
someone to manipulate this election?
How do users interact with the voting system that I've Designed
is it possible to hack the end-user and somehow convince
them to use the system in a way that they're not supposed to,
like, you know, can I tell people to download the wrong
mobile app? Maybe it's not even a security
issue in my system, but it's the way that I communicate things
about it, so we've done a lot more threat models.
We've tried to figure out like, what's actually important for
the blockchain. This is the same thing.
Like if you want to sit down and start developing security
properties, for a piece of blockchain software, what
properties are you going to write?
What are the interesting properties to express?
And in order to answer that question, you need an accurate
understanding of your threat model.
We use a couple tactics for building threat models.
We use Mozilla has rapid risk assessments.
Most frequently there are really gray 30 to 60-minute scripted
interview that you have with a developer to help them
understand, what's actually, at risk in the software they've
built. But then other times, there's
nist standards, there's all this Adam szustak kind of literature
that came. Microsoft, that are a lot more
heavyweight, but the rapid risk assessment stuff fits really
well into a one or two week Consulting engagements.
That's what we end up referring. If you want to see an example of
that. We have a great example of a
really well developed threat model up on our Publications
repository. That we did four votes, a
blockchain voting system. That's the area where all this
stuff overlapped. It was quite entertaining to us
to get a client that had both but you know, you can see what
it looks like and we'll be publishing more of those as time
goes on. So hopefully there's stuff that
people can learn from. Okay, we link to that as well.
We've talked about the security vulnerabilities of individual
smart contracts but now it gets even trickier.
Right? So basically in the defy space
and then the open finance space composability is key.
And we have seen several attacks and vulnerabilities over the
just over the last past months who's Gateway was leveraging
some weakness in composed protocols.
So what do you think we should be doing about that so who Be
responsible for checking that thing's actually fit together
and that basically interfaces work.
And is it the people who actually build the blocks and
thereby also the interfaces or is it the people who are kind of
use these money Legos to build, like more complex, protocols or
should the users check? Or should we have like an
external body? That kind of satisfies, these
kind of composed protocols, what's your take on this?
Yeah, so I mean for better for us, there's no gatekeeping.
Like I can't, you can't tell me that I can't put code on the
blockchain. So, ultimately, this is what
creates all bunch of surprises that people have to deal with
the defy space. I think is really immature like
it's a beta, use case for etherium, and for blockchain
technology in general. And people need to understand
that people are throwing a lot of money in to defy applications
right now and are kind of holistic, end-to-end
understanding of exactly. A whole Field.
Works is very limited. So I expect that there's going
to be failures and that there's going to be these new use cases
that people come up with whether it's a flash loan or a
deflationary token or like, whatever people end up
designing, that flips, all the security properties.
I thought I had on its head. So the D5 space, I think users
really need to understand. It is a work in progress.
This is not like, just because I've got a couple of Legos,
doesn't mean I can just start using them today and not suffer
any potential consequences like theirs.
Always going to be some downside risk and the downside risk in
the D5 space right now, is really high because that level
of maturity just is not there yet.
I think there's a lot of other things than defy space that kind
of caused me concern. And for people listening to
this, they can't see my body language right now, as I'm kind
of like nervously, rubbing myself just like all the defy
space stuff, stresses me out. You know, there's assets with
really low liquidity, even ignoring flash loans, there's
things that people Very limited amount of money can interact
with and cause failures for other people.
There's all this Reliance on external oracle's we're not
everybody that's deploying a defy application.
Has evaluated how secure their system is against that Oracle
being manipulated or how many oracle's being manipulated or
what the cost is to manipulate an oracle.
Like just that kind of full system thinking really isn't
there. How can you have full system
thinking, when, if the number of oracle's you can have in a
system is basically unlimited. And then, on top of that, like
the number of bugs, you can have per Oracle is unlimited, right?
You're basically just reducing the security to the lowest
common denominator and you don't know what that is.
So it's like, you know, it's virtually impossible.
Then in that case, if you have external inputs to a system to
ensure full security Yeah, I mean, it gets even worse.
When you start thinking about external contract, interactions,
right? Like, there's a lot of players
out there, you know? The compound folks, I think are
one of the best where they whitelisted.
A lot of the interactions they have with external contracts
because you just don't know exactly what everyone's going to
do and you need to carefully, consider all the interactions
between yourself and a counterparty before you start
engaging with them. There's a lot of contracts out
there that say that they're ERC 20 but don't actually implement
the spec is the easiest example. There's a lot of Acts out there
that, you know, if you don't flow through all the second
third, fourth order, effects of what it is to interact with a
given contract. Then there's the potential that
somebody finds one of those composability issues and gives
you a really bad day. So I think it's really incumbent
on defy applications at least right now to take these baby
steps towards full decentralization and not exactly
go for hey I'm going to interact with the whole world and
everybody on the blockchain could call every single function
of mine. And I'm going to call every
single function with areas and it's going to be great because
it ends up taking On too much risk to quickly.
So I think a lot of people in the D5 space need to take some
baby steps and be sure of themselves.
When they take those steps through either Security, review
really effective and thorough modeling work with economists to
figure out a second sentence and actually understand what kind of
risk their inheriting. Maybe do a threat model, right?
Understand what kind of risk that they're inheriting by
interacting with those systems or creating certain features so
I thank you that stupid. Resting.
So there's a different kind of bug that we don't think about
often after basically composed abilities and everyone's at the
Forefront of everyone's mind. But there's one thing that a lot
of people who've been in the ecosystem for a very long time.
I deathly afraid about but that we rarely talk about.
So bugs in the compiler just because if there's a bug in the
compiler that kind of causes a certain era and basically it's
kind of people don't generally check bytecode and in their
audits. We kind of rely on on the code
itself and the AST and so on. We don't really check the bad
code. So do you have thoughts on this?
So are we too reliant on individual?
Contact compilers a little bit? You know I like I said earlier
the quality of the compiler that most of us are using solidity
compilers extremely low. So the testing just really isn't
there and there's an ongoing discussion right now.
About improving. Some of that testing by actually
importing some of the techniques from Slither and offering more
standardized interfaces for Or software like ideas and testing
tools so that we don't accidentally break the entire
ecosystem of tools that people rely on to test the software
that they that they create, you know, by updating the compiler.
But it is a little bit of a misconception that we're not
testing by code. Most the tools out there that
are doing property, testing, or doing some bollocks
verification, or are doing abstract, interpretation are
actually working on the bike code.
So, when you get a manual review, normally that manual
review is of the solidity. That Wrote.
And then if you have a static analyzer, that's that
economizers. Usually, again, going to be of
the solidity that you wrote. So, you inherit some potential
bugs from the compiler, but when you're writing properties,
writing security properties. In general, the approach that
Engineers have taken towards building.
Those tools has been to evaluate those security properties on the
byte code that gets put into the blockchain.
The risk is that the emulation that you're doing for the
etherium virtual machine to evaluate that bytecode, might
not Be identical to the etherium virtual machine that powers the
blockchain. I have a python aetherium
virtual machine that's built inside Manticore.
Is that identical to the execution of the etherium
virtual machine on the real blockchain, I try to get it to
be as close as possible but there's always the potential
that there's Divergence was there as well.
So, you know, this is a little bit of a like, you know, Turtles
all the way down but every single one of these things that
you do ends up reducing the scope of what can go wrong.
Like it doesn't hurt you. To do a manual code review and
find bugs and solidity. That only helps, it doesn't hurt
you to depend on a from scratch python implementation of the
etherium virtual machine. It generally only helps you find
bugs. So these things over time like
you get this preponderance of evidence like okay I've reviewed
the the source code I've statically checked it with a
linter. I have property tests that run
on the etherium virtual machine and then I'm only going to
compile it with a safe version of the compiler.
So for instance, a wreck mendacious that your lab it's
makes and our reports is. We don't want you to use the
latest version of the solidity, compiler.
We actually roll back two versions that we think are safe.
I don't know the exact version that we recommend now, but
generally, we look at the maturity of new features,
they're developing and take our own view as to how safe we
think. The long term will be for each
of those those features and then we you know, recommend something
before those features were introduced.
So things like the API encoder version to the Parsing, that
kind of stuff, I would absolutely avoid and use a
version of the solidity. Compiler.
That's older since less likely to have bugs, you know,
introduced into your code. Sure.
And so are there other dark horses in the blockchain
security space for that should keep us up at night?
I mean, how do you feel about non Quantum resistant code?
Is that something we should worry about?
What, what should we do? What should we worry about that?
We're currently not worrying about.
So give us some nightmares. Yeah, sure.
I mean the post Quantum stuff. I'm not I'm not super worried
post. Quantum stuff does not keep me
up at night. I think it's still an open
question if quantum computer can even exist, you know, a lot of
people talk about the the number of qubits and whatever that you
can get and how that's growing over time and there's a larger
number of cubic quantum computers, but that's not
actually the, the metric that people use to evaluate, a
quantum computer works or not because you have to deal with
noise, the larger, your Quantum system is the more noise that
you To look through in order to get results out the other end.
And what we've seen is that as these quantum computers scale
up, so does the noise and the end up kind of equaling each
other out. So I don't think that like,
Quantum Computing is a five-year problem.
It's definitely not a 10-year problem either.
I think it's more of like a 30-year problem and when you
look at it on that time Horizon, there are some really good
research results that are out for developing post Quantum
cryptography trailer B has a great guide on our blog called a
guide to post Quantum cryptography.
Where we review you'd a lot of the nist candidates for Quantum,
cryptography and broke down the different categories of
lattices. I saw Jenny's codes hash
functions and all the other kind of potential ways to get there.
So I think that on that kind of time Horizon, cryptography can
kind of Mosey along and end up giving us a good result and
prepare us for the future if quantum computers were ever to
exist. And that's, you know, I'm not
discounting that's a possibility, but I'm just saying
that it's hard. So that's, that's definitely not
what keeps me up at night, honestly.
Like, I think the outlook for, Contracts is pretty good.
Like I think that in 2020 we figured out a lot of the things
that we needed to know to build smart contracts safely, like
there are tools that are available for people to use.
There's a process that they can follow.
There's a lot of lessons learned from other failures and we
generally know the foot guns that exists inside solidity.
Even though we'd prefer they weren't there.
And I think that four teams now that are developing software,
they have the tools to have the knowledge judge and its
capability within the realm of capability for them to produce
secure software. It's just a matter of whether
they do it or not. So generally, what keeps me up
at night is that there are people just sling and code that
there are people that just ignore all these lessons that
don't do their research that don't use the best tools
available to them to produce software.
The adherence that we have two people that use Slither to check
code before they put it on. The blockchain is still pretty
low. I don't know exactly what the
numbers are, but I'm sure it's not 100% and that's a, that's a
huge problem. There's 90 flaws that slither
finds that the solidity compiler can't.
That's kind of what keeps me up at night.
There's all kinds of new stuff that gets developed like the
defy space. I'm kind of like, I've learned
to love the bomb, right? Like, I know that's an immature
space. I know there's going to be hacks
and failures and that's what I expect to have happened.
So when I see it happen, I'm not surprised.
So I'm comfortable with the fact that we're going to discover
more potential things that cause issues like like flash loans or
deflationary. Tokens or people that just don't
implement, the ear C20 spec properly, and people
inadvertently, trust them that they do.
There's a lot of stuff there, I don't know, I'm a little bit
jaded, so I think I've seen all this stuff before, so it doesn't
really scare me. I have to be able to sleep easy
like that. I wouldn't be able to work in
this field. If I went to bed every night,
what's the worried about the world being there?
When I woke up in the morning, Balmy as the space continues to
grow and more say like real world assets or like
institutional Finance comes into this space.
Like, do you think at some point there will be a trade-off where
we either have to go towards more centralization or more
white listing or like kind of pull back because you know, if
just composability just grows exponentially.
That means also like exponentially more.
Purity issues and security, vulnerabilities, and
institutional Finance is not going to want to deal with that.
So what's the future look like? Yeah.
So the defy space I think is a really special case, right?
Where if you want to have some defensively unit of code out
there, that's capable of remaining safe, despite changes
to the environment around it forever.
Then you need a really solid understanding of all the
economics of that system and all the incentives that people have
to interact with it and all the safety margins for all the bad
things that could potentially happen.
You know, we recognize that. So we partnered with prison
group, a small team of extremely talented.
Economists that, Like us used to work professionally with large
financial institutions and Central Central Banks and that
sort of thing to offer a combined service offering called
maenette 360 where we look at things from a combined economic
and security perspective. What was good in 2019, what?
What used to pass the bar in 2019 of like, okay, I don't have
re-entering. See my contracts.
I can put this thing up on the blockchain.
That is not the bar in 2020. So like there's a higher
standard of proof that I think people are going to need as time
goes on. So we're certainly not done like
just because I wrote Echidna and Manticore and Slither doesn't
mean I also security solved and if everybody runs this stuff
before they put on the blockchain, the totally safe.
Like there's certainly much farther that we have to go and I
think having a really solid formal understanding of the
economic security of your smart contracts is probably the next
level to that and that's where trilobites is investing.
A lot of our tool development and a lot of our Partnerships
and a lot of our own teams kind of internal knowledge transfer
and learning. So what's the future of software
security? And you know what role is a i
play in terms of being able to detect bugs.
I mean like right now there's like human Auditors but you're
also relying on a whole lot of tools like we kind of gave this
analogy to like a spell checker or something like that.
Right. Like grammarly.
Right. But the next logical, step would
be my mind. Be like, let's now build like
some artificial intelligence that goes in and tries to figure
things out and perhaps based on in some input or some like that.
But like what's the future look like?
Your opinion. Yeah, I don't know AI plays a
huge role. So a eyes been really cool.
There's a company of things are called tab 9 that created an AI
driven software, development tool like an IDE, they took the
entire universe of source code on GitHub and they trained a
model around it. And then when you're inside of
your IDE, you can just type out one word and then press tab a
lot of times. And when you press tab, a lot of
times just fills in the code that it thinks you're writing
based on the model that range from GitHub, which is super
cool. But for security, you know, a
lot of what makes the program secure is, an understanding of
your security properties and the ability of you to test them and
the tools that you use to do, that aren't probabilistic their
deterministic, that's what you want.
I don't want like a model that's kind of fuzzy that like, you
know, the these guys out on the internet so that it was safe.
Therefore, it is like, that's not the standard of proof that I
want. I don't want to train a model to
tell me that my code is safe knowing that it might be wrong
or that there might be, you know, things I trained it on
that are incorrect. Instead.
What I want is I want like symbolic execution to Fork off
every potential configuration of every single function in my
entire smart contract. I'm provided deterministic
result back to me that it's impossible for me to reach a
state that I don't want. That's kind of what security
looks like in the future. You know, we participated in
this DARPA program that tried to examine the exact same thing.
Back in, 2014, 15 and 16. It was called the For cyber
Grand Challenge. The way it worked was I don't
know if you know the development of computers like deep blue.
But back in the 60s and 70s, they used to.
That was the first time that people created robots that would
play chess my robots computer programs that would play chess
and the computer programs were just so awful at their jobs that
they would get creamed with even an amateur chess player and
there was no way that they would ever win a game.
So they ended up making a league of only chess-playing robots.
Where the chest Robots would play against each other where
they're all, just as dumb as the other one.
And then, eventually they learned from each other and they
figured out strategies that worked, and they build up a huge
repertoire of potential attacks and defenses.
And then after years of training against each other, they were
able to play against him. Beat human participants.
So the DARPA cyber Grand Challenge was supposed to be the
same thing for computers. It was a league where computers
could play Capture the Flag, a simulated hacking exercise,
against each other. And then the winner of that
competition would play a capture the flag.
In Defcon CTF, which is the largest Capture the Flag
Channel. Our most prestigious, let's say
I capture the flag challenge in the world.
We put forth a machine to do that, but the kinds of
advancements that you need to improve software security, tools
are things like automated crash, triage better program analysis,
tools that help you understand and model, what a program is
doing and where data is going, those kinds of things are really
critical to the future of software security, not so much
the AI portion. It's not a clean kind of
Relationship between software security and chess.
If any of that makes sense. I actually have a great talk
with smartphones are Revolution where I try to review all the
research that's been made and the progress that's been made in
the last 10 years or so at automated program analysis and
software security. Generally, I think the future
for this kind of stuff is that a lot of the tools are going to
get embedded into IDs. Like right now it's a
specialized task for me to use a program analysis tool.
Like a symbolic executor Or some other kind of program verifier
you need a security expert to do it and it's a third-party tool.
We have to go download it separately, but I think the
availability of a lot of these tools inside standard
development tool kits will increase over time, so hopefully
the bar of knowledge required to use them goes down, more people.
Take advantage of them and then we end up finding a lot more
bugs. There's also the potential of
like using them as Gatekeepers in the talk.
I talked about things like you know, a lot of people that are
developing apps today they deploy them to an app store.
The go out to the IOS app store or the Android App Store and
there's a really nice point of control where you can use these
program analysis techniques to ensure that every app that
everyone has access to meets a minimum bar of safety.
And I think that the blockchain kind of has a lot of the similar
characteristics as an App Store where there's probably some
upfront verification that could happen prior to entry.
Like are you this tall to board the ride, kind of deal that
might end up making things safer.
So that's where I see kind of, you know, maybe the two-year A
lot of the stuff in two years, there might be a test to see if
you're tall enough to board the ride to get on.
Maybe the ethereum blockchain but that might be an anathema to
a lot of the like cypherpunks out there that really don't want
to do gatekeeping. Yeah.
They'll go for kit and take their toys somewhere else.
And yeah, and then they'll go build their own blockchain and
we'll start with the same problems all over again.
Dan, thanks so much for coming on.
Working people, find you and Reid and we'll link to all of
these great post you mentioned in the show notes.
But where would you like some people?
Sure. Yeah, you can follow me
personally on Deke. We do that on Twitter.
You can also get the trail B at drill bits.
Our blog is exceptional. Are highly recommend is getting
it. We try to have fun with it.
Yeah. Blog dot trailer b.com and then
if you're in the market for building smart contracts you
should go look up our repository called building secure contracts
which includes the accumulated lessons learned from all of our
security reviews and how we recommend clients, build secure
contracts without us. That's going to walk you through
all of our Tools a lot of our guidance checklists, tips and
tricks. All that good stuff is right
there. Awesome, thanks.
Thanks a lot. Thanks for having me.
It doesn't end here there's much more of this conversation and
you can hear it by signing up for epicenter premium as a
premium subscriber, you'll get access to a private RSS feed
where you can hear the interview debrief which goes on for an
extra 20 minutes. You'll also get exclusive access
to Round Table conversations with epicenter hosts and bonus
content. You won't hear anywhere else.
Go to epicenter dot rocks / premium to join the community
and support the podcast.