Monero Village - Handling Broken cryptography in cryptocurrencies
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 335 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/48727 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
DEF CON 27301 / 335
8
9
12
14
32
38
41
58
60
61
72
75
83
87
92
96
108
115
128
132
143
152
158
159
191
193
218
230
268
271
273
276
278
295
310
320
321
335
00:00
CryptographyBitCommunications protocolMusical ensembleComputer animation
00:46
Communications protocolOperator (mathematics)Information privacyMobile appCommunications protocolMusical ensembleGame theoryDifferent (Kate Ryan album)Mechanism designPhysicalismInformation privacyScaling (geometry)Computer animation
01:39
Source codeOpen sourceCausalityGame theoryMathematicsCryptographySoftwareImplementationBlock (periodic table)Serial portProof theoryInformation privacyVulnerability (computing)Communications protocolMechanism designLattice (order)Ring (mathematics)Link (knot theory)Database transactionSingle-precision floating-point formatModule (mathematics)Programmable read-only memoryConvex hullSinc functionInformation privacySoftware bugCommunications protocolQuicksortDatabase transactionMechanism designCartesian coordinate systemBuildingAuthorizationConstructor (object-oriented programming)Different (Kate Ryan album)Numbering schemeCryptographyVulnerability (computing)ImplementationMathematicsMoving averageInstance (computer science)WeightPoint (geometry)Mixed realityNatural numberMobile appRight angleKey (cryptography)SoftwareForcing (mathematics)CodeRule of inferenceOpen sourceBitInformation securityMathematical analysisSource codeLibrary (computing)Musical ensembleComputer animation
07:48
Local GroupMiniDiscHacker (term)Maxima and minimaSoftware developerRule of inferenceComa BerenicesCryptographyWindowGame controllerVulnerability (computing)Information privacyBlock (periodic table)SoftwareElectronic signatureSource codeHacker (term)Projective planeRootComplex (psychology)Database transactionCausalityPoint (geometry)Different (Kate Ryan album)Group actionSeries (mathematics)Figurate numberCommunications protocolSubject indexingComputing platformData miningPatch (Unix)Power (physics)Total S.A.Parameter (computer programming)NumberVirtual machineSound effectBitMusical ensembleComputer animation
13:56
Zoom lensLocal GroupTelecommunicationImplementationBasis <Mathematik>CodeControl flowLine (geometry)InformationKey (cryptography)Point (geometry)Communications protocolIncidence algebraProjective planeBasis <Mathematik>Multiplication signCryptographyInformation privacyGeneric programmingInheritance (object-oriented programming)MultilaterationDigital photographyComputer configurationData miningQuicksortDifferential (mechanical device)Mechanism designImplementationVulnerability (computing)HypermediaSoftware bugShared memoryOnline helpPort scannerCASE <Informatik>CodeInformationReal numberDisk read-and-write headInclusion mapVirtual machineMereologyTelecommunicationServer (computing)PlanningMusical ensembleComputer animation
19:29
CodeTelecommunicationControl flowLine (geometry)InformationMathematical analysisCommunications protocolSigma-algebraProof theoryInformation securityEuclidean vectorDirected setRing (mathematics)Constructor (object-oriented programming)Proof theoryFrequencySoftware bugResultantBuildingQuicksortLimit (category theory)Key (cryptography)Functional (mathematics)Address spaceBlock (periodic table)Software developerInformation privacyoutputAlgorithmMultiplication signHash functionDigital electronicsInsertion lossCommunications protocolCodeComputer programmingSource codeCASE <Informatik>Lattice (group)Mathematical analysisDifferent (Kate Ryan album)Point (geometry)AnalogyHeat transferNumberStapeldateiInformation securityTelecommunicationGame controllerSoftwareFood energySingle-precision floating-point formatMusical ensembleSequenceComputer animation
25:02
Pairwise comparisonBitError messageQuicksortDifferent (Kate Ryan album)Information privacyMechanism designProof theoryRange (statistics)Musical ensembleComputer animation
25:54
Zoom lensLattice (group)Group actionMusical ensembleGraph (mathematics)Touch typingSoftware developerSource codeComputer animation
Transcript: English(auto-generated)
00:00
Alright everybody, let's give it up for Ruben Yap to talk with us about Zerocoin. Yay! Yay! This guy. Alright man, here you go.
00:25
Okay, hello everyone. My name is Ruben Yap from the Zerocoin team, and today we're going to be talking about basically how we handled protocol topography in cryptocurrency, and some of the challenges and lessons we learned from the, you know, gas chocolate floor that
00:42
was Zerocoin. So, just a bit about ourselves. What else? How about this? So we are practicing a coin that we launched on our main app in 2016, and we actually pioneered the practical use of Zerocoin, which is actually different than Zerocash,
01:01
and it was actually one of the earlier kind of practicing protocols that actually introduced the burden and game mechanism. We're currently using a different privacy protocol that we replaced after Zerocoin for Sigma, and we're currently working on something called LAND, which is also being considered by Ammon as a physical scaling solution from there.
01:24
We have a team of about 90 people, which, you know, most, more than half are developers, and two in service, the one which is here, and six involved in operations, including me, who are working all around the world, and most of us are full-time.
01:40
So the thing about dealing with bugs in cryptocurrencies are popular and difficult, and the more that we settle the true cryptocurrency, the more difficult it is to actually deal with it. Like, for example, the first thing is the decentralized nature of these networks, and, like, for example, you know, if you have an app, and the
02:03
app's born as a bug, you just, like, push out an update and everyone updates, right. But the key point of, like, you know, blockchain and those decentralized networks is that you cannot force people to upgrade, you cannot upgrade if you want to. And what happens is that, let's say, if you cannot just turn off a fix,
02:21
you need everyone to agree and all that kind of fix to turn off, and it's about convincing not just, you know, your users about the pools and exchanges to actually update the journey without actually causing panic. It's really important not to cause panic, especially with cryptocurrency.
02:41
Now, one of the biggest challenges of open source software is that actually every single release has to be accompanied with the associated code. Meaning, let's say, when I'm fixing the bug, the fix to the bug will have to be committed to GitHub before I can make a release, and that's a real problem because by committing the fix, I'm
03:03
going to hear more about the flow, and that's also a real issue that the tool is also really bad. It's really hot because, let's say, if you suffer from a panic, if, like, coins are being created out of the net, those coins are sent with changes and bought by innocent people. It's very difficult to say roll back the damage you can
03:21
say because, you know, you have innocent people holding the coins. And, you know, we don't have that whole, like, a 10-year classic situation. So, you know, in many cases, you cannot just undo the damage, and most of the damage is done. So, what are cryptographic flaws?
03:41
You know, we have to sort of distinguish them from, let's say, like, software implementation flaws, and the cryptographic flaw is the flaw that happens in the actual mathematics of it. It's not just the software bug in the code, but actually sort of, like, there's a problem with the building block. And, you know, there's been actually many, many sort of
04:01
documentation and software bugs, even in Bitcoin. There's been, like, you know, Bitcoin very old, little instances where over 184 billion coins were created out of the net. There was a software implementation bug, there was Insela, Zcoins, and stuff that were really, really long, which was also a bit bad. PIVX was the stuff that did it as well. And then all of these, like, those were pure, whole
04:22
software implementation bugs that didn't actually go down to the problems in the mathematics. Now, these are some of the examples of what cryptographic flaws, and it's kind of a hotball to privacy points because of, you know, we use, like, cryptographic mixing of methods, and, you know, there was a Zcoin
04:41
vulnerability that was actually live for two years since inception, and no one actually really knows right now whether it's been exploited or not. We never had an implementation bug that technically was never exploited, and, you know, they could actually tell that there was no sort of
05:01
There was a huge Zcoin inflation bug in April 2019, and it was actually resulting from a failure of one of the zero of the groups. It actually created about 67,000 coins, about 10,000. Luckily, that's less than 1% of certain that it didn't supply. I mean, the coin supplies are like 8,000 or so now.
05:22
But, you know, it's still something that it cannot retroactively fix. So, just to make you understand, for those of you zero coins, here comes the privacy protocol that allows you to mint, which is the destruction of the coin, and then the spam, which is the
05:41
redemption of brand new coins with no previous transaction history. So, it was actually, like, the first application of zero coins, which proves that at least they solved the spam mechanism to provide privacy, and when you sort of compare it to, like, you know, other privacy mechanisms, like CoinJoin brings signatures, brings the coin join again,
06:03
like obfuscating transaction rules, so hiding the prop, and zero coin tends to try to break the transaction rules between the coins, because the brand new coins don't have any transaction rules to the previous build. So, with zero coin, and we probably
06:21
should have looked into it a lot harder, and the origin of the zero coin paper was written by Amy Nance, Kristin Gunnar, and Matthew Green, and we sort of wrote the zero cash paper, which now is the foundation of Zcash, and, you know, we were like, when Zcash was started, we, you know,
06:41
we only had one program, we started it as like an experiment, and we trust that these people are gonna talk to the authors, you know, one of the talk to the authors in the world, and we kind of trusted it, and that was one of the bigger problems that we had. It was actually rather critically written, and certain constructions of the proof, that means it wasn't actually fully described,
07:02
it was only described in the software library that they created, and that's a big problem, because then, you know, it's a very different thing than, let's say, everything through the paper and understand how it all works, rather than going through individual critical analysis to actually find out does this whole scheme actually work.
07:20
There's pretty little single paper exactly described in the way zero coins implemented in the library, and you're quite waving through bits and pieces of other papers here and there, and yeah, it's not as if we didn't take a look at it, you know, or we actually engaged a cryptographer to actually try to find force in
07:41
implementation in the zero-coin security model, and we actually did find two of them, which was then allowed an attack to create, to destroy coins of homeless users while on transit, and an attack that can actually hijack like the dancers. Let's say if someone creates coins to redeem to themselves, those coins
08:01
can be redirected to someone else. However, we will talk about this later that isn't as serious as it seems to be, because to actually pull off this attack successfully, you would actually need the control attack power of more than 51%, and control of the network would be able to selectively censor transactions.
08:21
If you're going to control both of this, you have kind of effective control of the network, but we'll talk a bit more about that later. Now, April 9th, which was a zero-coin, which was a protocol, was hacked, and due to a floor crew, and coins were actually created without commit, and this vulnerability actually impacted
08:41
all projects utilizing zero-coin complexes. But we were only wasn't attacked. So, just kind of like the timeline of the attack, we actually noticed a spike in zero-coin anonymizing transactions. We do monitor the network just to stop saving up, and even usually,
09:01
the problem with the privacy opt-in is that generally, the pickup of such transactions is quite low, and suddenly you see that every single block with a max number of zero-coin anonymizing transactions, we were starting to wonder what was happening here. What happened actually was the one-point spans the data that
09:22
exceeded the birds, and we knew something was definitely not right, that the index was supposed to not happen, and we were actually kind of really stressed out. We didn't even know where the floor was or knew that something was wrong. We immediately contacted the mining pools that we know to inform them to request the
09:41
availability of zero-coin spans. That's not done as consensus-related as the parameter that pools can choose from. Zero-coin spans, they want to process the block, and we told them, you know, we are actually investigating certain zero-coin interactions, and please reduce this to zero while we investigate it.
10:01
Luckily, most of them did, but there was still some unknown pools containing processing, so this hack was continuing to happen, and we couldn't really stop it because of this decentralizing feature. We actually did inform other major projects utilizing zero-coin of possible issues, like there's something that's not right here. We noticed more
10:21
spends than mints. We don't know if you guys are affected, but maybe less creative, and we'll keep it to see whether we can finance these machines here. On the 16th of April, because, you know, we had even zero-coin spans without telling the whole public, but it was already too long. It was already like one week ahead, and people were starting to complain, why can't we process
10:42
zero-coin spans? And we had to come out of public and noticed that we had to pass the pools to the zero-coin spans, while it has to be in the United States. Now, after three days, well actually, it's already like 10 days since we discovered the hack. We finally discovered the root cause of the flaw, and we confirmed that
11:02
it was actually a cryptographic flaw among the proofs, and this was discovered by our own developer, Peter Shiraev. We did a limited disclosure to the zero-coin working group to tell people that, hey, you know, this is something that we know is definitely something that's wrong. We think that everyone's affected, but we didn't want the exact problem
11:22
yet, because we didn't want to give emanation for this other coin to potentially be affected as well. But we just wanted to tell them that the problem is real. Maybe you want to start looking at it, and we are in the midst of patching it, but you might want to keep zero-coin as able, because at that point in time, the other projects, like the PIVX, had already
11:41
disabled the zero-coin protocol. Prior to this hack happening, they were vulnerable to a different software implementation called a RAP Series hack, and they had disabled the zero-coin, and we were done. Keep it disabled for now. They were actually kind of deactivated, and we told them, since you have it disabled, just keep it disabled
12:01
for a little while, and we'll figure out what's happening here, and I think that's what we did. On the track, we emailed the developer, hey, do you know how I did it? Didn't really engage with it too much, just kept him off to work with us for a while and then we didn't really engage with him.
12:22
So on the platform of April, we actually released an emergency software update, which actually disabled the zero-coins at a consensus layer. Just remember, we only disabled it at a mindful level, and it still spans getting through those blocks. We only had two daily and we're kind of
12:41
looking at a kind of small coin, so this is not something that we're not going to replicate in the future as we grow bigger. And once the hard fork came to be, the patch was completely stopped and we needed a total number of damage for 69,000 coins. And the only
13:01
reason why we knew about the exact amount of damage is that actually, if you knew the exact floor of the zero-coin, you could actually create perfect forgeries, but because the understanding just kind of got simple. And the spends that we created had a certain signature
13:21
that was slightly inflated in size, and that's why we knew it was 69,000 coins we created. Now what actually happened was when this happened, we did inform the working group, one project actually kind of jumped the gun. I didn't know what, for whatever reason, the April and May, they had exposure first before we did
13:41
and said, oh, you know the fact that we are committing a zero-coin is this April on our network. And that's the to put it this way, this is the big move because other projects would have not secured themselves. Other projects did not have a mechanism to address this April zero-coin like that.
14:02
And this was a real big problem for us because although we had already secured ourselves, all these other projects were still using zero-coin, did not have a clean way that was delivered very quickly. And this actually required us to come up with a different, like a quick disclosure to say okay, this is what's happening, we're not going to
14:21
exactly tell, but we're going to advise you later. This is one of the real problems that really kind of hit us really badly. Now, on the 10th of April, luckily all projects that we were aware of had this April zero-coin other by sports platform. And sports is
14:40
kind of like, for those that are using the Dash master code, Dash master code, they can actually have like a sort of master key that can turn on certain features. So for those points they have a busy time with that just ended off, which is great for stopping and having not secured the decentralization. And that may include disclosure of
15:02
graphical vulnerability in any part of it. And after that, two months later, we finally deployed a replacement privacy protocol that we actually have been developing since early 2018. So it was actually in the plan that we needed to place this zero-coin. So what actually did we learn from the incident and
15:22
we think there are actually three pillars in delivering a graphical flaws which is capability, communication, and more sharing. And the first thing is that no one wants to deal with other people's shit. Especially on a budget basis. When a cryptographic flaw happens, you have to act
15:42
relatively and you try to look for help just in case you couldn't solve it yourself. We were really worried this could actually kill the point. And we reached out and we went to the automated researchers. Everyone was busy and didn't really touch this problem. This was a real big problem. And I think that's actually a really key differentiator between
16:01
projects that manually just implement other people's privacy protocols versus those that actually develop it themselves. Like for example with Zcash, there's so many other privacy projects that use a Zcash privacy protocol. Similarly, there's a lot of projects that use a generic privacy protocol. And sure, they didn't get how it works,
16:21
but they don't really look in their bodies. And that's really dangerous because then they rely on whatever the parent project is just to make disclosures to them. And sometimes that doesn't really work as well. And sometimes you really cannot trust everybody. We'll talk about this a bit later. Even photographers who engage
16:41
as a party can actually screw people over as well. Especially if they're just a contractor as well. They can exploit it themselves or they can punish it and get people to go out of all options and gain credit for themselves. We should actually see what actually happened with the zero-coins protocol and profit data.
17:00
Now disclosure and working together with other projects and competition experience, even though we all incentivize to fix the zero-coin, our experience with this whole zero-coin thing was so bad that we're going to think in the future, we might not be able to which is very sad. Maybe you guys
17:22
you know, there's a real breach of trust on our head. So you have to carry the machine. So communications you know, we have a server key that we can talk to the community and the PR infrastructure and the code itself. And to the community, of course we need to
17:41
try to be as honest as possible to let people know that there's a problem, but again you have to send that information in a least while to fix the problem and you know, totally sort of lock it down and we also need to make sure that you're not causing an impact. But oh my god, there's all this speculation and all the things we might need to try to really affect the trust of the
18:02
project. Now the thing that's really important is the engagement of media and PR. When something goes wrong, you really need to be proactive, not just reactive and made a mistake before it kind of just reacted to the problem.
18:20
And in this particular case, when we didn't make a problem, we knew the problem was straight away, we shut the problem, we said this is our official press release, this is what it is if you have any questions, talk with us and we really want you to make sure you got the criteria of the bug correctly. Now just to give you an example of something that went really wrong. So remember those two bugs that we found previously
18:42
that were not that critical, which was called Berlin Zero Coins was found in a profit. Then we actually approached all this media and said, I found a particular flaw in the zero coin and the problem was that we had engaged him to actually find this flaw that we had patched it, which was actually a scan dream flaw for activation.
19:01
And what had happened was in all the boos were saying critical flaw of the zero coin or the distinct how many fakes. And actually as I mentioned it is actually really difficult to think about a critical flaw. So it's really important to just proactively reach out instead of waiting for people to crack it. Now with the infrastructure of folks, you know
19:22
it's always good to look at this centralized approach we should be knowing who our main stakeholders are, especially with exchanges and mining pools. And we have to make sure we open a good enough communication with that so that when we tell them hey, this is zero coin or this is emergency out there, at least you know, they trust us enough to take it at our word.
19:41
It's not a bad feeling but we need to have to build that relationship out there. And the most thing I think is through the code we need to communicate through the code remember, every single sort of fix the input has to be committed to the source code before we can actually make a release. And one way to do it that I think is
20:01
the purpose of doing one which is the Zcash name which is basically waiting for like a huge update and then sort of sneak the fix in. There's something like a drawback to that because that means you need to open for a time amount of period or that's like what we did to kind of downplay the fix. So for example when Bitcoin did that and they had inflation
20:22
bugs, they said oh this bug we fixed the bug that solved TDOS but then actually it was a source of inflation bug. So what we did was to downplay the fix and committed the code to get parts of it. It doesn't result in any sort of panic but later on it will be possible to disclose it. So the last
20:44
one I guess is a caution you know don't transfer any of these numbers like those batch protocols and whatnot. And as I said understanding protocols is quite different than doing a deep analysis of it. And the zero controls are quite tricky to find. The protocols have been around for a long time
21:01
you know people have looked at their protocols from different programs looking at it and you know every time it's okay right and unless you actually pointed it and said there's something wrong there. So the case you actually wrote it you know analyzed and received a portion of it. Now
21:22
don't be in a rush if you point anything wrong. Especially since this is something we have been guilty of for example our proof of world algorithm called MPT. You know there was a new paper out that promised to be better than every hash more than what happened. And we
21:41
spent about 8 to 10 months trying to build this out and develop it. And about two weeks before launch there was actually a paper out that said MPT is broken you can attack it in this way. MPT ended up in just three wonderful years worth of work. So we had to actually invest in more
22:01
research to actually fix it. Took another year to get that paper out and deploy a fix. And I think it's better actually rather than keep on looking at the new shiny things to wait for all day on the trip before you launch it. I mean it seems to work off this now. But you know it's like very competitive. I don't know what I'm thinking.
22:21
What I'm thinking is quite take on the most sexy technology. The other thing I would say is that considering the circuit breakers and limiters that can slowly lag. So for example in Ziploc, we actually had a limit of say 500 to 0.4 block that could be spent. It's almost like similar to almost like a
22:41
Bitcoin having like a one minute block or a minute grand loss of tax. I think it's quite, especially when you're building a such new technology it's probably wise to have some sort of you know like limiters in place and I guess that actually saves us because of that block we could limit the damage even if it's actually the one
23:01
we didn't talk about today. But it's not our idea and it has to be you know it's just one of the many fixes that we could do. But we have to be very very careful that we're not introducing standardization. I'm actually personally really against sports because you know it's basically the developer who has the key
23:21
to be able to turn on functionality. And I think especially with the privacy point, that's horrible with that. Like a law enforcement or like a government entity goes to that. Turn on privacy I think that's a problem. So this is quickly what we placed at Ziploc. We are currently on
23:42
Sigma which is the base of much better papers. You know the construction is relatively simple and the security portion has the security proof. And it works. It's actually on zero-point. It uses different photography and it's a lot smaller. It uses small proof sizes
24:01
and it also does the addresses there. So this is already currently deployed on our network. It's like the energy line. The lens that some of you may have already heard it really expands on the camera and it mimics the need for building and attaching and fixing all the issues by actually finding the right ones as well. We also have the ability to have
24:22
anonymous payments. That means you don't have to keep moving back to the base later. But it requires a self-spam and it's a problem that we're looking for and it's a problem that if the lattice is to be ever considered to be deployed on the network this is a problem that needs to be solved. So oneros' proposal for the lattice is kind of different
24:42
than how Ziploc intends to use it. So I think oneros, if I'm correct, intends to do a large use, like a thousand or so, the way the lattice and zpoints are intended to be used is as a similar point where you're doing building and attaching. So it's
25:00
different approaches but also using the same analogy. So this is a quick comparison. I just hope that there's a bit of errors in some of the proof sizes. So this is just a sort of overview of the different privacy mechanisms. So as you can see, oneros solves most of the issues with the non-B-set size, which is something
25:22
that's active in research. I think that this needs to be corrected, is that in the lattice and sigma, the proof sizes, when you're giving all the proofs, including the auxiliary proofs, the range proofs, is about 3-4 to the y. You can also
25:40
R-negative. So it's about similar to narrow, and I think everything else is relatively correct, and you can take a look at how that's where your problem is when you compare it to other stuff. So yeah, you can find more in the old, very practical way, if you want to
26:00
find more of a lattice with that other side, if you have a z-point you can leave it off. So yeah, I'll take some more action if anyone has that.
26:26
These are really cool. So right now, I mean, originally we
26:41
did think about having the lattice on in Q1 2020, but after this incident, maybe we should slow down a bit, and that may be a wise choice, but we do have to put the graph in our way since we already know, and hopefully we can share some of that as well.
27:01
But right now, I'd say that we're kind of packing up, making sure everything is fine and we also need to do more development, but then, I think in one or two months time, the development really started again, so that's kind of what we're about.
27:38
In touch with Saran and we're really open,
27:41
we actually agree privately that we need to share our source of what we've done to Saran before we begin open source. Thank you very much.