 So you know that nightmare you have where it's a half hour until your talk and you decide to add like 10 more slides And then somebody phones you and says your talk is right now when you're missing it That's the nightmare that I just had so I apologize for being a little late This is kind of a weird talk and you are gonna hit a couple of places where I've got these like great slides I was just about to throw in This is kind of a weird talk I was invited very graciously by the organizers to come and give a talk to this community And sort of there are various things that I was interested in talking about And I decided maybe against my later better judgment that the thing that is probably the most interesting that's happening right now is crypto currency and I say that even though there are a huge O-load of interesting things that are happening as well One of the other things that's happening right now is we're finally seeing Deployed applied crypto. That's actually making a difference. We're seeing TLS really take off We are seeing a huge variety of different crypto attacks We're finding backdoors in real systems and these are all really really interesting things and yet when you think about the Change and the rate of deployment of new crypto nothing really compares to what's happening in the field of crypto currency right now So I wanted to give a very high level kind of overview talk that goes back into the past Maybe looks at the future and talks about some, you know, some of the things that went wrong in the past Why it took until maybe 2008 2009 to get to what we have today and what maybe we can do in the future Okay, so quickly. Let me just give you my background of probably a bunch of you don't know me I'm I teach at Johns Hopkins and the work that I do is primarily applied crypto So the work I do is really in kind of systems security taking cryptographic protocols Building them putting them together and actually getting them out into real implementations a lot of the work I've done is TLS. We looked at a lot of messaging systems stuff Messaging systems, but I would say the majority of the work that I've done since I was a grad student Where I did my thesis on oblivious transfer is on privacy of preserving protocols. I also have a blog Which I try to write from time to time Somewhere in the last few years. I co-founded this weird cryptocurrency, which is called Zcash Which is really cool because it uses zero knowledge to actually give privacy and that was a really weird experience all the way through Talk about that another time. Okay, so Well, this thing's not gonna work on it So why are we gonna talk about crypto? What is so interesting about this? Well, there are a whole bunch of things happening that kind of affect us Also, one of the things that's happening is that we're losing the right to the word crypto And we're losing this largely because you know, unfortunately crypto is so much more interesting when it has money attached to it And most of the crypto we do, you know, we work on doesn't really have that So it's obviously affecting us in some very silly and obvious ways The other reason that you know, this is so interesting to us I guess is that the amount of money and the amount of hype and the amount of interest in this field is really really taken off it's taken off to an absurd amount in December, I think Ethereum went up to $1,400 it was insane it's dropped back to only insane levels, but you know things are happening It's really kind of interesting at least to the rest of the world So whether you love it or you hate it Cryptocurrencies are kind of exerting this gravitational pull on our entire fields And that's a good way in a bad way. So for most people Cryptocurrencies are their first major exposure to cryptography. That's great. Not really the most interesting crypto But like anything that gets you in the door And it also lets us explore and deploy some really interesting novel crypto I think we've had more use of multi-party computation Techniques in the last few years and then we had prior to that we've had more use of zero knowledge proofs and other kinds of things Then we've had in the past the kind of bad news about this is that If you stare into cryptocurrency It stares back at you and it can also kind of distort our research priorities. Sometimes it's not very good way This is kind of a problem. So what am I going to talk about today? Well, one of the things I want to talk about today is some history So I want to go back in times the 80s. I want to talk about payments of cryptocurrency I want to talk about some of this sort of practical stuff that's happening right now I want to talk about some of the research directions of you people in this conference have been working on and I'm going to cop to the fact that many of the problems that interest me are privacy related and I've been told by people outside of this field that privacy is not the most interesting problem in cryptocurrency And I don't believe them because I think it really is But you know these things there are other problems to be solved too I'm going to focus a lot on privacy and kind of the post-crypt is all is that I'm also going to talk about some kind of random bad cryptography that I turned up came up across on Different cryptocurrencies and that's not really part of this talk Okay, so I want to go back in time to the 1980s Kind of the theme of this part of the talk is what went wrong? We started out with all of these dreams and we got paid How did that happen? What exactly happened now to sort of understand what happened with the payment System research of the 80s and maybe the 70s and so on you have to start with the understanding that there was already a banking infrastructure So banking was not a new problem We already had plenty of systems that were basically databases that held account ledgers of different people's Balances and we're updated in all sorts of pretty standard ways So banking is not the problem the problem that we started to tackle in the 80s was the specific problem of I guess we call them retail payments small individualized payments between customers and merchants or between customers and customers and When we talked about this kind of this era of payment research We're really talking about cryptographic payments talking about payments that actually had some level of high assurance maybe cryptographic security and For better or for worse a certain amount of privacy attached to them There were a handful of problems that had to be tackled to make this stuff work So first off to build any kind of payment system you have to tackle any kind of digital payment system You have to tackle the problem of double spending double spending is a huge problem So if you have anything that's a digital currency, maybe not a quantum currency But if you have any kind of digital currency, of course coins can be duplicated and that means you can spend the same money twice So we have to build systems that can capture double spending and prevent it or maybe trace people who double spend and so on If you're going to build a system and your reference points catch then you also need some kind of system that allows you to make sure that pays and Other parties in the system have some kind of privacy so that you don't leave too much information during payments And you have other questions like how does money get into this system? You need a connection to the banking system in order to move money around It probably the the vast majority of the research we in the cryptographic community did in this area is Into this field called the cash which began with Chong back in 1982 The paper is actually cited as 1983 And later with Chong Fiat and nor these papers I'm sure many of you have read the cash literature at least have seen this very early Blind signature based cash But basically these cash systems all had a very similar architecture So they're a cash model with this kind of added privacy privacy was the new problem that people were trying to tackle in this research So anybody who wanted to get money to get a redeemable token or a group of redeemable tokens And ultimately the problem that was being solved was detecting double spending in a situation where users have it right? Let's take a look quickly at the Chong 83 crypto 83 paper This is probably the simplest e-cash system you could build By the way, it doesn't have a bottle of water The charm 83 scheme is the simplest thing you can build basically in order to get some money out the bank has a signing key It signs blindly using an RSA blind signature pulls down a serial number the pair has that serial number they can reveal that serial serial number in the signature to the merchant and Ultimately the merchant can then present that pair to the bank and the bank can verify that the serial number has appeared before again So this is 1983 Okay, I want to forward fast forward to 19 to 2005 And this is a scheme by Kamenich Hohenberger and Lizzie Skylde which was published at Eurocrypt 05 If you look at this scheme, it looks very familiar It's ultimately got some much much more powerful crypto in it But it's the same scheme at a low level uses a key This is like December in Bitcoin Okay, the CHL scheme uses you know it uses much more powerful technology so down here We have a PRF so we can we can pull up entire wallet coins instead of just one coin So instead of signing a serial number will sign up key for a PRF We'll compute the serial number using the PRF on some counter And then we'll use a NISIC to make sure that you know everything here is kosher will give the resulting NISIC to the merchant Okay, we do this and it's much nicer and much more efficient, but it's really the same set There's nothing new and this is 20 something years in the future from John So the things did not fundamentally change in the entire E-cash field and there was a lot of Research done in the E-cash field so a huge number of work. I searched electronic cash on Google Scholar I got 35,000 results. I don't know if those are actually 35,000 results But there are a lot of papers done on this and they come in variations. There were online offline schemes There were schemes that use trusted hardware. There were schemes that would reveal your identity if you double spent But fundamentally the main problem in all of these works was privacy because privacy is kind of the problem to solve The question we should ask and this is you know not the deepest question But why did this E-cash work not take off? Ultimately in order to build an E-cash system and people try David John tried with Digi-cash You really needed to have two things you need to have a centralized bank and that bank would be a single point of failure That bank went down everything was gone your customers had nothing and You needed some way to get money into your system Which typically was just another version of you need a bank and it's very hard to get banks to Partner with you when what you're trying to do is build a privacy-preserving system that doesn't allow nation-states and banks to trace you in 94 EU regulations came out that basically said the only people who have the right to issue prepaid debit cards Was were banks and that basically killed Digi-cash because this this meant that their entire business model couldn't work In 90 in the US 9-11 saw huge new laws that basically meant that anybody who was trying to operate a currency whether it was You know E-cash or not was was actually shut down and many of these people had their doors kicked in So this idea of centralized electronic cash prior or not was really a non-starter The question you should ask is were these actually technical failures or were they just Policy and the answer to that question is kind of who cares doesn't really matter They're indistinguishable if you have a certain type of policy environment and the only technology that can work in that policy environment is something that you know is not gonna work there Then you have a technical failure So you have this centralized problem and ultimately we focus maybe too much on privacy, which scare regulators too much Any solution we had is going to have to work around these manufactured problems So to switch gears a little I want to show you one other payment proposal that was made in the 90s And this one was much more conventional was developed by visa and mastercard How many of you have heard of secure electronic transactions? Okay, that's a surprisingly large number. I am amazed by that This was a proposal that was developed by visa and mastercard so really that the people who are in the industry with access to the payment technology and it was a pretty sophisticated cryptographic architecture based on credit cards Using digital certificates. The idea was to get assurance authenticity and confidentiality for some things You have to love this kind of early 80s Clipart the basic idea of the system was that there was going to be an online party and you as the payee was going to have a Digital certificate that you got from somewhere you were going to authenticate yourself using your certificate You're going to go to this online party and they were going to then just authenticate to the merchant for you And the key here was that you would never have to reveal Your credit card information directly to the merchant because merchants couldn't be trusted with this We didn't have SSL working back then very well. And so this was kind of the solution to all that and If you look at this, this is probably the biggest technical feature of that system This is a little system that allows you to verify a transaction is authentically signed Without knowing all of the inputs to the transaction meaning that I could give this to a merchant without giving the credit card And if you see this is like the world's Smallest mergel tree if you look at it on the side, so they were kind of anticipating Bitcoin at this point This this was kind of a sophisticated as a God so two hash functions, and you know another hash function that would go into Okay, once again, why did set fail as he did So the obvious problem was it required users to get certificates and nobody wants to get we still don't want to get Certificates nobody wants to deal with key management and identity management So you have to manage your own keys plus you have to bind them to an identity and you have to store them somewhere And that is really unpleasant and very hard. So this idea of binding keys to identities is just not really workable So what are our conclusions from this 1980s to 2007 time period? Well, all of the cryptographic solutions we had were too complex or they were in undesirable features like privacy And I say undesirable quotes meaning that they were unworkable for the people who had to enable them The commercial solutions including said really didn't support a special case which was person-to-person payments Which turns out a lot of people really want to do web browsers at the time the kind of most advanced technology did not support fancy crypto And the end result was this little company called PayPal which came up as a company that was Starting up as a palm pilot to palm pilot payment system Came along and developed a system which was probably and I'm gonna say this in a really nice way But probably the dumbest possible solution you could get when you think about the different paths that we had to build And what I mean by dumb is not that the technology was done It's very very complex and hard to implement But essentially what PayPal was was a very expensive fraud layer built over the existing banking and credit card Infrastructure and the reason that was kind of annoying was how many of you have ever seen something like this on PayPal But PayPal is legendary for not letting you make transactions Not letting you make payments or take your money And the reason is that the only way they made this work was by putting a huge amount of fraud detection on top of things Okay So the good news from all of this is we got PayPal. We also got Elon Musk. So now we have a lot of this And You know we've got Peter Deal. That's fine, too. So, you know, we had some good outputs or some outputs for this All right. So moving on In 2008 everything changed I think this would be really the wrong audience to spend a lot of time talking about the details of Bitcoin But I think it deserves a slide or two just to sort of explain, you know, what was so fundamental about this development Okay, so the main thing that the Nakamoto paper and the Nakamoto implementation did was it replaced this idea of a trusted server with a distributed ledger Ledgers are complicated to build Turns out you need some kind of consensus technique and in this case Nakamoto invented a new consensus technique And that consensus technique was really new and unique and had some special properties Which I'll talk about in a second that made the system work very well when it was standing up There were some obvious things that came along Puzzles were introduced to handle consensus to generate the funds. This was not a new idea I think way day and other people had thought of this before but these ideas were kind of integrated and One really really fundamental invention was that that Bitcoin eliminated the need to identify to find keys and identities together Just use your public keys and identity Hey, when you consider these four major Developments and this is going to be like the worst summary that I've ever made Everything else is really straightforward, right? It's all straightforward crypto You use public key crypto to initiate payments use secret keys to sign and validate payments Once you have a ledger that works you can do this very simple. So everything else is really just engineering So what are the lessons we can take from Bitcoin? Well, the first thing we can get is that picking the right consensus algorithm makes a huge amount of difference I think that we kind of underestimate how important the Nakamoto consensus was. I want to give a quote I thought I saw a lane in Europe This is from Elaine she and Raffi past this is from their paper They presented the other day actually in the blockchain session Which is that blockchain style consensus achieved certain robustness properties in the presence of sporadic participation and Node churn that none of the classical style protocols do This is sort of one of these anodyne academic statements But it's really fundamental if you're starting up a volunteer network with nodes that are not reliable that are peer-to-peer nodes That are going to go away constantly You need a consensus mechanism that does require setup that is able to handle these cases and even today as we're deploying things like proof of State protocols, we're still fighting with this problem There are a number of protocols that are proposed to use things like verifiable secret sharing inside of a proof of state protocol Well, that requires that a bunch of nodes stick around for ten minutes No, don't stick around for ten minutes And this is something that you know unless you have a system that can actually achieve these guarantees You don't have a workable consensus for this particular set Obviously the lesson of we need to eliminate this key identity management thing because nobody wants to deal with identities Obviously that simplifies the problem and then there's this kind of third lesson of Bitcoin Which I call the human beings are weird less and this is gonna seem This is gonna seem like the most trivial. This is not a technical observation. This is probably the most trivial observation make Here is the lesson that we Seems very obvious in retrospect But is not was not obvious and would not have been obvious until you actually tried to deploy a cryptocurrency like this Hey, so the thing that we learned in 2010 11 12 13 14 15 so on Was that if you build a system that has tokens that have a guaranteed supply or predictable supply? that are secure in the sense that People have a high confidence that the entire system is not gonna be shut down or the system is gonna fail Then weirdly enough they're going to assign value to those tokens It's bizarre. We didn't know this was gonna happen The fact that it happened actually has really big implications probably bigger implications than anything I could say about technology or crypto currency Now the value that people pick for these these tokens are you know arbitrary Maybe they're 10 times too high Maybe there are 100 times too high, but the fact that they have non-zero value at all is really significant This is something that you can't figure out Until you build this is really the major observation. I think What were the limitations of Bitcoin? There are a lot of limitations now? I'm a little bit focused on privacy. So obviously the privacy limitations are what matters the most to me There were functionality limitations as well Scalability and ultimately sustainability limitations for Bitcoin, which we're still sort of tackling The good news is we've solved the scalability limitations just by making like 150 new coins So that's all taken care of The serious news is that you know, there are a lot of different people taking different approaches But the first really huge limitation of Bitcoin was no the privacy limitation. This is a fairly old graph You can tell it's old because that big red dot there says silk road But this is a map of the Bitcoin transaction graph as it stood back in 2013 This is a whole bunch of people buying drugs on a publicly available ledger and doing this in a way That's gonna last forever Now they're doing this with pseudonyms But they're not doing this with good pseudonyms because ultimately those pseudonyms are gonna leak or they're gonna be linked to exchanges and people's Identities could be denominated. So this system does not work particularly well Now when I show you this next slide some of you may have seen this This is a slide from an NSA program called monkey rocket. How many people have seen the monkey rocket slide a Really small number of people saw this. This is actually the result of a VPN system that the NSA set up in 2013 2012 They set up a VPN overseas and they allowed people to connect their Bitcoin nodes to it and as a result of that They saw huge amounts of Bitcoin traffic on the wire not just on the blockchain They were able to link IP addresses not just IP addresses. I think it actually says map addresses To this to this data So they were actually able to de-anonymize a huge amount Maybe a large fraction of the blockchain or at least the portions who went through this So anybody is very very hard to keep if you were one of these unlucky people or lucky people who went through this this particular Okay, so how do we address that? Well two different Things that we worked on or I worked on with a team of folks. I see Ali here, too We worked on basically adding anonymity. I'm not gonna go into the details of this I worked on the adding anonymity two different papers one called zero coin which used RSA accumulators It's your knowledge proofs to fix this and later a zero cash or a C cash and actually deployed this the reason I'm showing this Is more as a warning now. I said that we're deploying a lot of crypto and this is good When my grad students and I wrote the first version of the zero cash implementation We decided that we write a library We wrote this library put it up on github. We added this warning The warning says for God's sake don't use this in any kind of production currency Don't put money into this terrible implementation that we banged out in a month over the summer Now the reason I'm showing you this is this morning I copied it out of the git repo for a coin called Z coin Which is currently worth five hundred million dollars in terms of market cap Not only did they take all of our code unchanged, but they actually copied the warning into their code And so this this kind of stuff you can build things and they're gonna get deployed and they're gonna get deployed in scary ways It turns out we had a vulnerability in our code, which was that in one place where we had to check The value of a field element We forgot to specify that it had to be a field element and as a result you could double-spend currency by computing You know a or a plus some prime P or a plus to be and so on So you can make big mistakes when you deploy things So what other problems are there? Well, what do you have a ledger? I mean the obvious problems that don't offer you need some way to go from a ledger to or go go Let me rephrase that once you have a ledger you can do a lot of really interesting things So if you think about a payment system is basically just a state Transition where you have certain transactions that haven't been spent and you're going to some you know adding some new Transaction that happened to spend the obvious next step is to make this entire thing into a generic Evaluation of some function and make that function into something that updates the state on the ledger So this really is where a theory came from This is kind of the general trending future of all of these crypto currencies is will replace these very simple state update functions with This is great. So now we have a theory and we can actually control the spending of money in very sophisticated ways So I want to talk a little bit about some problems that kind of interest me and when I say this is the future I don't mean this is all that's happening in the future I mean these are a few things that I think are kind of essential going forward with modern currencies Okay, so the three problems that I think are the most interesting to me are How do we make blockchains and Bitcoin system Bitcoin type currency scale? There are very limited ways that we can do this. Most people know that the current Bitcoin and theory of transaction rate is about seven transactions per second. It's not very high I think that's seven maybe maybe Relatively high in fact compared to what it actually is practice if you compare this to visa and again most of you know this That you know the visa system could top out during holidays 40,000 transactions per second globally So these are not comparable. We need some way to actually make these systems scale to a reasonable Through but one of the ways that people have proposed to do this is they propose to do it using channels How many of you have heard of the Lightning Network? Okay, good. So the idea of a channel system is really really really very simple The idea is that you have two parties and they want to interact but they don't want to produce a lot of bandwidth on chain So what they're going to do is they're going to establish what is basically an escrow Don't worry about the details of how it's done. Let's just say they put some money in each person puts in some Money on the blockchain. They have one transaction that transaction be later unlocked using a digital signature made by both parties Or if one party goes away be unlocked. Maybe after a certain amount of time the idea of channels is extremely simple So let's say we have one party that puts in one Bitcoin another one that puts in zero Bitcoin Once they've done that on the blockchain they can go ahead and they can interact directly To produce new signed transactions that change the balance of that that particular channel They can do that many many times without ever going back to the blockchain at a certain point they decide they're going to close this channel They can take the last transaction back to the chain and they can cash out whatever each person's balance is There's a dispute. There's a mechanism to deal with dispute. Not very complicated The Lightning Network is actually up and running on a test. This is a Visualize and explore that basically shows you all of the different lightning nodes that are online nodes that are available to establish channels and The lines between them represent individual payment channel relationships that have been established on the blockchain Let me zoom in on one of them So this is a particular node and you can see it has channels with other nodes But also some of those nodes have channels with still further on so this allows us to send money Technically speaking anywhere, but what are the problems with these networks? The first thing you have to see is that if we're just talking about a single hop payment channel Go privacy at all between the individuals who are communicating So if these two individuals have a payment channel open, they have to know each other's identities They have to know every spend that the other person makes If we go back to the Lightning Network Lightning doesn't really have a solution for this because it's not privacy technology What Lightning does is it says if you want to achieve privacy so that you don't know who the two endpoints are on this Channel you have to place it more intermediary. So instead of a single channel The Elon will open up a channel with I1 I1 will open up a channel with I2 and so on all the way over until it gets Peter and the idea here is that as long as these parties in the middle are not colluding Hopefully Peter will not learn Elon's identity. Does the system work? Not so well First of all it requires that to get any privacy at all we have to make extra hops which nobody wants to do in any sort of system like this We're not even sure there are going to be a series of channels that go from one person to the other And we're not going to be sure that they have enough balance inside of them to make this work But even if you accept that all of those things work There is a really significant problem with the Lightning protocol Which is that the transactions that people use to generate these things to allow them to atomically close Have to share a value called a hash log That means every single person in this channel is going to share a value H And that value H basically binds together Every node of the channel which means that if I3 Colludes with I1 even if I2 is honest the channel can still be linked together Denominase so it's not really un-enrouting it's something much much we hear How do we fix this like what's it fixed for this channel? Channels are supposedly the future of crypto currency. We're all going to be using channels to buy our coffee and pay our rent We want some right? See how do we fix this? One obvious idea is we could use Chami and E-cash. We already have this technology. We spent 30 years building it Let's deploy it in this set In the simplest one channel case we can basically treat one party as the bank We can establish some some balance between the two parties and now whenever one party wants to spend money Elon can let's say withdraw some currency From David over here and then spend it back anonymously back to David We're assuming David has many channels open and doesn't know who's spending what money so this seems like it's a pretty simple solution What happens if we want to go to two hops? What if I don't have a direct channels of the person I want to pay? Is there a solution to this problem? Anyone come on. We're not we're never gonna. I don't have a channel with rent I need some way to go to the bank and maybe Brent does have a channel the bank There's gotta be a simple solution to this So it turns out that if you turn this around in a sort of strange way you can make Chami and E-cash work For two hops and what I mean by this is we can elect David to be an intermediary and David can basically act as a bank Elon can connect to David withdraw cash and an exchange Balances with with David and Peter can do the same thing where Peter initiates a connection to David in the middle This is great And if we have a system that allows us to exchange both positive and negative balances now We have a way for one person to send money all the way through by sending for example positive one to David And then David could send you know positive one over to Peter. So this system works Can it work for three hops? I don't think so I don't actually see a way that you can go to longer numbers numbers of hops in a system like this It seems like Chami and E-cash Fundamentally breaks down when you try to go to longer channel lengths And so this is because disparate channels have to be tied together in systems like this There's no obvious way to make these work in a privacy-preserving way So this is kind of a big open problem if we're going to go to a world a layer-to-world Where we're going to build channel networks between people we have to find a way to build longer channels that have privacy None of the current techniques really seem to work very well for this So another problem that interests me is this idea of replacing proofs of work It interests me but a lot of people are working on it and doing you know kind of kind of neat work on this So we all know that Bitcoin is consuming vast amounts of energy I think the last I heard it was consuming as much electricity as Switzerland to compute the proofs of work But secure the network we need to do something about it There are people working on doing something about this the most obvious solution to this is to replace the proof of work with something That is cryptographic in nature where basically what we're doing is we have individual nodes with signing keys And those signing keys can be used to sign blocks or establish consensus between different parties How do we elect those nodes with the signing keys? Well the proposal that's currently on the table is to use proof of state Which is to say that people have a lot of money Where we trust it as the folks who can actually establish these can actually sign blocks Hey, so how do we do this? Well the basic idea of all of these protocols is we first go through and enumerate all the major stakeholders the protocol We make a list of them publicly revealing their identities and then we scale that list according to their stake And then we sample from the list Where do we get the randomness to sample from the list? We go to NIST Do we go to random.com? I think that's actually one of the things I have in a later slide No, but seriously, where do we get randomness from? In the Bitcoin network or any of these networks? This is this is kind of an open problem. So there are a handful of solutions to this There's a really excellent work on this particular problem that's happening here at Eurocrypt So in the session the other day there was a paper that actually dealt with a particular solution to this Previous year there was another one Which I can't pronounce at all that tried to do this and I believe some version of this is currently deployed in a real currency called Cardano right now Okay, so the thing that's really fundamental about all of these systems is they require some kind of randomness to sample from The original Ouroboros I can't pronounce it used an interactive protocol between potentially hundreds or thousands of nodes to establish these random coins that we would use for sample and the idea was we had a Resilient protocol that could survive the loss of a certain number of people, but what happens if too many people go away? It's not really clear if this protocol is going to work The latest version of the protocol deals with it uses a slightly different approach and uses grinding resistant hash function Which is based on computational Diffie helmets based on the idea that yes What we're going to do is we're going to have individuals provide input which we're going to hash together to produce data Produce this apparently random beacon, but in these kind of protocols somebody always has to go last And that person can grind they can use their hash power to sample many different inputs to find one that biases the output of the random points And so these solutions try to build hash functions that actually prevent people from grinding and actually trying to find biases They're useful to them under some relatively strong assumptions about what kind of things might be useful how much of a bias You can actually live with and the thing that's really interesting about this to me Is it's the kind of result that you can prove on paper? And I think it's really interesting but in order to see if it actually works you need to deploy it experimentally And so it's really exciting to me that crypto currencies are actually allowing us to do this kind of stuff So the last area that I want to kind of talk about is being really interesting to me is let's turn this problem around So far we've been talking about how cryptography can help with crypto currencies, but maybe crypto currencies Are you raising your hand? Yes. Oh, okay. I thought that was a question there So maybe crypto currencies or blockchains can actually help us build cryptographic systems so one of the things that people have been working on is Including myself and some other folks as well is let's imagine that we have these trustworthy devices Do we have trustworthy devices? Well, okay, so maybe we have secure hardware that we trust to be somewhat secure and There's this huge field that is gradually developing of building cryptographic Confuciation techniques which in theory hypothetically some of our hardware back and some are pure software program obfuscation allows us to build hopefully trustworthy Devices or circuits that can perform certain types of computation So let's assume we have one of these devices, but let's assume that it has no ability to keep state And this is a very realistic assumption particularly in software program obfuscation world because of course Software has no ability to keep state at all Okay, so these devices, you know, we can build them inexpensively from hardware We can we can get them from wherever we want and what we really want to do with these devices is compute multi-step Interactive computations meaning I want to run a program on some input get the output and I want to do that run that program again Another setting where this happens all the time is imagine we have a network of trustworthy computing devices where we're performing a single multi-step program But the program is run on a different device at each step Is there a setting where that matters? Well, every smart contract system is already in that setting as are a lot of serverless systems like Amazon lambda AWS lambda and other systems like that So the idea that we have to synchronize state is not really, you know, it's not a surprising idea So how do we do it? Well the obvious solution is imagine we have a secure computing device that has a key I can always have a user send it inputs that's that computing device We can get an output as well as an encrypted version of whatever state needs to be kept by this program And that's great. Next time I want to run the next input on the next step I just pass in that encrypted state and I get an output as well as a new encrypted state. What's the problem here? It's trivial replay attack. If the device has no internal ability to keep state I can always pass the third input along with one of the previous encrypted states And I can get that device to compute a new output for me And I can continue doing this as many times as I want. If this is some sort of interactive cryptographic protocol That's being run by the device. I could potentially completely undermine the security of that protocol. So what can we do? Let's imagine that what we have is Something like a blockchain. So we have a publicly verifiable ledger Probably verifiable just means we can post the string to this ledger We can get back something like a signature or some kind of verifiable proof That the string was posted and also just get a copy of the full ledger and we can send that to the device So given this it's actually really simple to keep state. We can send our inputs to the ledger We can get back the ledger contents in a proof We can send those ledger contents onward into the device and the device can then verify the ledger to see What step the step it's on and can send back an output as well as an encrypted state and you know go into more detail about this You can basically build systems that are rewinding resistance simply by you did to the fact that they are interacting with some kind of ledger This is really important smart contract setting where we're dealing with private contract where we have kind of secure devices So I think this is really interesting I'm sort of curious to see what other things we can do particularly in the setting of cryptographic I want to talk I want to shift from research topics to a couple This is this is the part that I said would be kind of unrelated to the talk a little bit more amusing hopefully I want to talk about some of the worst failures in crypto currencies now one of the Hypothesies of us deploying all of this crypto is that we are deploying it in a setting where smart people are going to break it Essentially, we're building the biggest bug bounty in the world. Somebody can find a flaw in our crypto They can come to us and they can actually tell us tell us anything. They just steal our money This is probably the most embarrassing one I found big rail which is a I'm not even sure what big rail is they lost a hundred and seventy million dollars worth of nano XRB tokens Because they place the balance checks for their system on the client side in JavaScript This is this is probably the most embarrassing Let me move on to one. That's a little more subtle. Okay, so this is a Adventist you weren't totally wrong Okay, so there is a website called random.org Random.org produces as you can imagine produces verifiable randomness Now random.org on January 4th, and this is a few years back switched to HTTPS from HTTP and What this meant was that people who are calling random.org in order to get randomness we're now getting in a 404 error And it turns out when you serialize 404, it's not actually a very high entropy seat And for various reasons having to do with their implementation They were trying to export this together with some other secure forms of randomness and they didn't do that They actually replaced it and so every single wallet Every single public key that came out of this started with one B9RE and a whole bunch of people lost a lot of money So this is the kind of thing that happens to the cryptocurrency I'll not just give you one more example along these lines My favorite Ethereum bug bounty submission was a case where somebody implemented ECBSA But they wanted to make ECBSA nonces more secure. So they exorted the message being signed into the nonce Turns out that this produces a trivial Bias that allows you to pull out the private key in about 256 signatures Which a bunch of people then proceeded to do so this was then you know, very And I wanted to kind of wrap up with my favorites Cryptocurrency Iota And I'm gonna skip past the part where I don't invent their own hash function I'm gonna skip past the part where I don't invent their hash function and inventing their own artificial intelligence to invent I want to focus in on the Iota Signature Iota uses hash-based signatures Nobody quite knows why but these hash-based signatures are Winternet signatures Winternet signatures have this really neat property that you start with a single secret key vector at the top And you hash forward all the way down until you get the public key and the idea is let's say we're signing bites What I'm gonna do is to sign any given bite. I'll start with a secret key and I'll hash forward a Certain number of times. Let's say I'm signing the message three I'll hash forward three times until I get to a secret key and then I will output That hash result as part of my signature and I'll move on to the next bite in the message Well, one of the problems that crops up with these signatures is that obviously if I get a message that has a Bite three is its first bite Anybody can hash forward to turn that bite into a four just hash the message one time pass the signature one time And you change the message to a four and everything is fine So this is actually a pretty easy signature to forge and the fix for this is to implement a separate check Some which you add on to the end of this the message before you sign it and the checks on has the property that you can't Subtract sorry, you can't increment any bite and signed message Without invalidating the checks on I won't go into the details of how the checks on calculated But you can figure you figured out yourself So it's really essential for the security of these signatures that the checks on work. Well, the normal checks on by the way is an addition Iota invented their own checks on And the way they invented their own checks on it does not seem like it actually guarantees that you can't increment Messages and as a result of that Oh, I should mention one thing these signatures are also used to sign messages that come from the centralized party that operates their network So if I have a message M And you can come up with another message M1 that is Greater at every bite position than M Then you should be able to hash forward until you get a valid signature on that message It would be very unlikely to find two such messages because they're out there. They're the outputs of a hash function If they were long messages if they were let's say the output of a full hash function However, it turns out that Iota only verifies one-third of the message which turns out to be 27 they say that they use a ternary. Yeah, he's ternary 27 trites and so which is equivalent to 20 27 bites. So this is not a Terrifically secure signature. I'm not sure it's exploitable, but this is not a terribly secure signature and I already mentioned kind of my my most Embarrassing example here, but I want to show you one last slide Which is that as a result of this hack? somebody went ahead and created 370,000 Z coins out of thin air and sold them for several million dollars on exchanges So these kind of things okay, so so my conclusion slide was the slide that I was fixing So I won't show you that what I really conclude with is that crypto currencies? You know, this is sort of a fun talk, but crypto currencies are really serious There's a lot of money out there a lot of people can get hurt if we don't do things right But this also kind of gives us a unique opportunity to do really interesting new crypto There are interesting problems out there that we have not had the opportunity to solve and we should be using our Kind of unique opportunity to solve those problems and actually deploy new ideas into this Thank you very much Questions, please go to the microphone Hi Right, I mean there's there's you know, there are two kinds of people right there people who think this technology is amazing I think the technology is amazing. I think it's super amazing to be able to send money to people instantly But then there are other people who are excited about this just because they see it as a way to get rich And that's kind of a drag like one of the things that will be really nice is when these currency values all drop back down to nothing We can kind of go back to like just kind of playing around with technology and right now We can't do that I So, I mean, there are some currencies, there are some tokens that have some really good ideas like these storage point, I think are super interesting. I don't know if they're gonna execute on them, but I think the idea that you could buy a currency in order to make, to perform distributed storage is a really, really good idea. I think Ethereum, you know, they executed, whether smart contracts really make sense or not, I don't know, but they had a very straightforward idea and they executed on it, they did a pretty good job. I think the problem is when you see a lot of these other tokens, and I give, you know, IOTA or time, but there are others that are, I think, much less justifiable, like where you, you know, maybe there's an application here, but I don't see how issuing a token specifically for that is better than just using a native cryptocurrency or any kind of currency to pay for the ultimate product. I think that's a real problem. I don't know how to judge that technically. A lot of them seem to be kind of hard to, you know. Yeah, maybe comment. First of all, about all these previous payment systems that started with the banks and for the banks. Oh, no. I feel like I'm about to get really swagged. With the bank for them, yeah. It was with the bank, but the banks were receiving well, for the banks, because they don't have any kind of established business. So when you come into business, you have to get into business. That was the problem in PayPal. P-13, they recommended towards peer-to-peer auctions that was open, how to do it, and that's how they started the revolution. Where it's said to, you know, and to fight with the other internal departments in the banks. I was in the banks. So, but the banks actually didn't care. It said it was not implemented. It served its purpose by stopping all alternatives. And then people did payment risk-raising cards over necessary things. Interesting. That's actually, it's all business-related, or therapy business, and whether we deploy technology properly, this is the thing we're looking for. Second remark is about security. So typically, in security, it shows we do security, and we have business funders who deploy all kinds of things. The bank guys, they are motivated by greed. They go out into attacks because they can extract money. And the Bitcoin is the first time the greed is the motivator of the support of the good people. So if we can find businesses, so that's the way to analyze the businesses now. So I agree with that. I think that people overestimate the number of smart ad guys right now. I think that there are a lot of things out there. And, jeez, I keep thinking about it. Like, I would have had some problems, right? And there was a bug in IOTA just a few months ago where if your signature had the letter M in it, it would give you the secret key. And my point is not that that was a particularly bad bug. That was a really bad bug, whatever. But my point is that that was in the code in a $5 billion allegedly currency for at least months, maybe more than months. And so I think it's true that the great thing about Bitcoin is it is like the world's largest pen test, where it pays for itself. But I think also we make a mistake when we deploy something and we say it hasn't been attacked yet. Therefore, it must work. And the reason that I get really nervous about that is new consensus algorithms in particular can work great for years until they stop working. And when your only real way to analyze them is to say, well, rational actors wouldn't attack this. Nobody's rational in this world. And so on top of that, you have this situation where eventually someone who's very irrational is going to do something to you and you won't really know. So I think people get very, very overconfident. Yeah, that's curious. You talked a lot about the current system, the technology behind the name blockchain has also found another life now in the price application world, it's called blockchain only, type version. And so in this context, I want to ask, will you see a perspective on blockchains without coins? Can they be live? Do they have to be using bodies? So I mean, there has to be some kind of payment to support for permissionless blockchain where you have some people lining. You need some kind of payment to support that activity. I don't know how else you can do it. For permissioned blockchains where you have individual nodes, you could just run that normal consensus algorithm. What's that? You need incentives. But like in private blockchains, they call them blockchains. They're not really the same thing. Then you don't need incentives. And in that setting, you would do some really interesting nice things. And I think some people are going to deploy that. I don't know whether it makes sense in every application, but I think that does. I just wanted to talk a little bit about privacy. I'll teach. I know it's not the only way that privacy is going to be joined in Sanctuary World for several other things. And I'm sure I will be there. How is this going to end? I mean, can you maybe, I don't know, say something about it? Sure. So one of the most exciting areas that's really big work done right now at conferences like these is the development of better non-interactive zero-knowledge group techniques and arguments. And I think that's really one of the most exciting areas, at least for me, from a privacy perspective. And so you mentioned bullet groups. I mean, that's the output of, I guess, Boodle et al. from last year, certainly two years ago, NeuroCrypt. And that got branded and has optimized a bit. These kind of non-interactive zero-knowledge groups are really exciting in terms of building any kind of privacy-preserving technology. So if all this stuff goes away and we just end up with a bunch of really great zero-knowledge-proof implementations, like I think that's a great outcome. So that would be really cool. You know, I'm not going to compare like Monero is its own thing and they do things with a different kind of technology, but I bet you at the end, they're all going to converge on using pretty strong high-end and reset system. I noticed that you mentioned monkey rocket, which is definitely a pretty interesting and a state program, but the most interesting in a state program is actually referenced by the monkey rocket slide, which is next to KX, or it's a key score, and that's that mass surveillance system. And things that you catch those are really surprised about. They fall short of the mass surveillance atmosphere. You know, the means production or miners create things or go to pools. Those connections are usually not encrypted at all. For example, they just send the VIPs. So you can actually trace the creation of a wealth and see who all the creators are from the mass surveillance project. And I wonder if anyone's actually taken into account the mass surveillance network adversary in addition to a cryptographic adversary looking at the distributed ledger parties. Clearly, people are looking at that one, not the rest of those things. So if you had to ask me the most interesting kind of systems crypto research that I would suggest people do for this area, it would be to develop really optimized and then the networks for the underlying peer-to-peer networks that are supporting all of these currencies. Because right now the best thing people have is to use Tor, but Tor's not optimized for this. Because every time you make a connection to a Bitcoin network, you're using a specific protocol that identifies you. So even if you do it over Tor, you're de-anonymizing yourself. So building something that can handle a specific case of broadcast flooding and do this in a very privacy-preserving way at the network level would be a really, really interesting project. There are a few people who've done things like this, but to actually build those kinds of systems would be really fun. But for example, with C-nash, if you want to do this mining, that doesn't seem to be a target because it's important for the launch. So that is a very massive amount of data. There is a massive amount of data for most of the mining. And they're recording a launch with C-nash. They have a really good idea about everyone who's ever participated, everyone who's ever lied. And when it comes to, you shouldn't do that because that's one nice thing about Ethereum. They don't have any insight. So is it the case that you wouldn't even want to use that over an hour or like longer? Because I would think you wouldn't, it's not, and frankly, it's just a TCP connection with your IDE. Some people just switch or replace the IDE. So is that a roadmap or some sort of thing you're gonna try to get so you can use it or get it? I mean, definitely, yeah. Like there's a lot of work to be done for C-nash for all. I think that's the key to currency in terms of engineering to make the actual network layer much more bright. So absolutely, I don't play in any of these projects or something. The one thing I would say is that mining is really a different problem, right? If miners aren't private, if everybody knows who the miners are, that's not great. But it's also not the end of the world in the sense that if you mine currency, you sell your currency, if we get privacy at least from that point, I think that's, you know, obviously to be perfect if everybody was totally anonymous from the end of the year. I mean, just having a good use. Yeah, I agree. Okay, if there's no more questions, then let us thank Matthew, okay?