Throughout this chapter, we've followed the development of DragonBucks (which was succeeded by CryptoniaCoin) and learned how certain mathematical functions can be used to secure a currency system.
However, along the way we hinted at some potential security flaws with the Cryptonian system, and you may have picked up on some of them yourself.
In this exploration, we’ll point out some of the weaknesses of CryptoniaCoin and start to look at ways to resolve them. We won’t be able to patch all the security holes in this quiz, but we will address each of them by the end of the course.
One requirement of the CryptoniaCoin system is that we're able to represent everything as numbers. This means that we need a way to convert transaction notes into a unique (which is also a number).
Consider a simple way for converting a transaction note to a number: concatenate the transaction amount, the public keys of the parties involved, and the date. For example, if we wanted to send coins from the account to account on then
What’s wrong with this method of converting a transaction note into a number?
Assume that all account numbers are the same number of digits and the date is always expressed with digits.
Suppose you wrote a note to buy a loaf of bread, but then realized you actually needed two loaves of bread, so you go back to the store and write another note to buy the second loaf.
If the cost of each loaf is the same, you pay using the same account, and it’s on the same day, then using the system we proposed on the last pane, those two notes would be converted to the same This is problematic because the two identical messages would have the same signature, so either
Suppose we make a rule that notes that are identical to an existing note are automatically invalid. Then, if you tried to use two notes with the same and the same signature, only the first would be honored.
If we want someone to be able to make two similar payments on the same day, we could try changing the way the is constructed:
Would either of these changes allow you to make two similar purchases on the same day?
For security, we never want a signature to be able to be used more than once, even for similar transactions. Fortunately, there are relatively easy fixes we can implement so every transaction results in different message numbers and therefore requires different signatures.
Different cryptocurrencies use different techniques to make this work in practice, and they’re all valid.
Because the fixes are relatively easy, this doesn’t represent a major security concern for cryptocurrencies, but it's something we need to be conscious of when designing a verification scheme.
In DragonBucks, the dragon doesn’t need to know anyone’s secret key — the system we built allows anyone to verify signatures. Whether you’re in charge of updating the account tallies or not, you can verify a signature using public information.
However, if you don’t tell the dragon (or anyone else, for that matter) your secret key, then there's no one to ensure that it’s actually different from everyone else's.
If you did have the same secret key as someone else, it would be pretty obvious since you’d also have the same public key. But you could also have a different secret key from someone else, yet still have the same public key.
We can see this using the calculator below, which implements the modular arithmetic of the DragonBucks system.
Try using and an of your choosing. Next, use the same and but set the secret key
With the sample values above, and should lead to the same public key. If you had the same public key as someone else but a different secret key, would your accounts be distinct?
Even if the modular arithmetic of our system protects someone else from being able to back-calculate your from your or a you've issued, it's still possible for someone else to pick the same public key for themselves by chance.
If you have the same as someone else, that means that your secret keys are the same in i.e. Though you each have a distinct for the purposes of the Cryptonian message-signing system, your accounts are practically the same. You would be able to sign valid messages on behalf of each other.
This represents a big security flaw — if you happen to choose the same secret key that someone else is already using, then you’d be able to spend all their money.
What could we do to reduce this security risk (while keeping the rest of the system the same)?
Even if controlling the issuing of keys did work, it would require trust in a central authority that controlled those keys, representing a fundamentally different type of currency.
While it may seem strange, the best protection against someone else having the same public key as you is simply increasing the number of possible public keys. The more possible public keys there are, the less likely you are to find someone else’s (whether you’re trying to do it or not).
Just how many possibilities we'd need for the system to be considered "safe" will be explored later in this course. But to give you a preview, some real systems use secret keys long enough that it would take more than random guesses before you could expect to replicate another user's key.
We claimed the Cryptonian system is secure because you can share your public key, without revealing the value of Indeed, you can't invert (undo, in other words) modular multiplication by simply dividing by the original factor and applying e.g. but that doesn't mean it's impossible.
If we did have a way to "modularly divide" by then would not be safe. Let's take a closer look at what it would take to do so.
Suppose that, instead of dividing by we multiply by another constant The goal would be for to have the following effect:
What property would we need to have for this to work?
If we could find such that then it would allow us to "modularly divide" by . We call the that satisfies this equation the "modular multiplicative inverse" of and denote it (not to be confused with the reciprocal of outside of modular arithmetic). So the that lets us "divide" by must satisfy the equation:
Even though we multiply it’s effectively modular division since multiplying by cancels from the expression in In effect, we use to unlock
For small , we can find a quickly with just guess and check.
Suppose the Cryptonians chose for their system. What is in
You can use the modular calculator below to help to find the answer.
The existence of is what fundamentally threatens the security of our modular multiplication verification scheme. For a small like the one we just looked at, you can find through guess and check without taking too long and easily crack the system.
Making bigger will protect against this simple guess-and-check strategy, but as it turns out, there are more efficient ways to find
In the next chapter, we’ll see why this security hole can’t be plugged without changing some of the functions that make up our verification scheme, and what properties we need those functions to have in order to be sufficiently secure for a cryptocurrency.
See you there!