Yesterday we learned from new Snowden leaks that the NSA is working to build a quantum computer. The Washington Post broke the story with the rather sensationalist headline, NSA seeks to build quantum computer that could crack most types of encryption.
Naturally, this raised much concern among the new Bitcoiners on Reddit and Facebook. The reality, however, is there wasn’t much disclosed that people didn’t already know or expect. We’ve known that the NSA has openly sponsored quantum computing projects in the past. The fact that it has an in-house project called Penetrating Hard Targets is new, but not really unexpected. We learned this project has a $79.7 million budget, but quite frankly that isn’t that much. And as The Post notes, the documents don’t reveal how far along they are in their research and “It seems improbable that the NSA could be that far ahead of the open world without anybody knowing it.”
Nevertheless, this seems like a good time to discuss the implications of quantum computing with respect to the future of Bitcoin.
Let’s start with a little primer for those who are unfamiliar with quantum computing. Today’s computers encode information into bits — binary digits, either “0″ or “1″. These bits are usually stored on your computer’s hard disk by changing the polarity of magnetization on a tiny section of a magnetic disk, or stored in RAM or flash memory represented by two different levels of charge in a capacitor. Strings of bits can be combined to produce data that is readable by humans. For example, 01000001 represents the letter A in the extended ASCII table. Any calculations that need to be performed with the bits are done one at a time.
Quantum computers, on the other hand, use the various states of quantum particles to represent quantum bits (qubits). For example, a photon spinning vertically could represent a 1, while a photon spinning horizontally could represent a 0. But photons can also exist in a rather weird state called superposition. That is, while they can spin vertically, horizontally, and diagonally, they can also spin in all those directions at the same time. Don’t ask me how that’s possible, it’s the bizarro world of quantum mechanics.
What this means for practical purposes is while a traditional computer can perform only one calculation at a time, a quantum computer could theoretically perform millions of calculations all at once, improving computing performance by leaps and bounds.
Now when journalists write things like, “In room-size metal boxes secure against electromagnetic leaks, the National Security Agency is racing to build a computer that could break nearly every kind of encryption used to protect banking, medical, business and government records around the world”, it naturally makes people think it’s the end of cryptography as we know it. But that isn’t the case.
Let’s consider the type attack most people think of when hear of quantum computers―a brute force attack. This is where you just keep checking different keys until you eventually find the right one. Given enough time, you could brute force any encryption key. The problem is it would take billions or trillions of years for a modern computer to brute force a long encryption key. But surely quantum computers could do this right? This is from Bruce Schneier’s 1996 book, Applied Cryptography:
One of the consequences of the second law of thermodynamics is that a certain amount of energy is necessary to represent information. To record a single bit by changing the state of a system requires an amount of energy no less than kT, where T is the absolute temperature of the system and k is the Boltzman constant. (Stick with me; the physics lesson is almost over.)
Given that k = 1.38×10^{-16} erg/°Kelvin, and that the ambient temperature of the universe is 3.2°Kelvin, an ideal computer running at 3.2°K would consume 4.4×10^{-16 }ergs every time it set or cleared a bit. To run a computer any colder than the cosmic background radiation would require extra energy to run a heat pump.
Now, the annual energy output of our sun is about 1.21×10^{41} ergs. This is enough to power about 2.7×10^{56} single bit changes on our ideal computer; enough state changes to put a 187-bit counter through all its values. If we built a Dyson sphere around the sun and captured all its energy for 32 years, without any loss, we could power a computer to count up to 2^{192}. Of course, it wouldn’t have the energy left over to perform any useful calculations with this counter.
But that’s just one star, and a measly one at that. A typical supernova releases something like 10^{51} ergs. (About a hundred times as much energy would be released in the form of neutrinos, but let them go for now.) If all of this energy could be channeled into a single orgy of computation, a 219-bit counter could be cycled through all of its states.
These numbers have nothing to do with the technology of the devices; they are the maximums that thermodynamics will allow. And they strongly imply that brute-force attacks against 256-bit keys will be unfeasible until computers are built from something other than matter and occupy something other than space.
To recap, if you could harness all the energy from a supernova and channel it into an ideal computer, you still couldn’t brute force a typical encryption key. Needless to say, if you are going to break commercial encryption algorithms you’re going to have to attack the underlying math.
Today, most public-key encryption algorithms rely on either the difficulty of integer factorization (RSA) or the difficulty of discrete logarithm problems (DSA/El Gamal, and Elliptic Curve Cryptography). In 1994, mathematician Peter Shor demonstrated an efficient quantum algorithm for factoring and calculating discrete logarithms that would break public-key encryption when used with a quantum computer. This wouldn’t break all types of cryptography, however. Traditional symmetric-key cryptography and cryptographic hash functions would still be well out of range of quantum search algorithms.
Impact on Bitcoin
Bitcoin uses several cryptographic algorithms―The Elliptic Curve Digital Signature Algorithm (ECDSA) for signing transactions and the hash functions SHA-256 and RIPEMD160. If the NSA succeeds in developing a cryptologically useful quantum computer, ECDSA would fall while SHA-256 and RIPEMD160 would remain secure.
The good news is that ECDSA should be relatively easy to swap out if/when it becomes compromised. It would be much worse if SHA-256 were to go down. If you’re not in tune to the mechanics of Bitcoin, SHA-256 is used in Bitcoin mining. At the moment, billions of dollars have been spent on custom computer chips that do nothing but perform SHA-256 calculations. If SHA-256 were to go down, those custom chips would turn into expensive paperweights. If that happened suddenly (as opposed to allowing for a smooth transition to another hash function), it would be pretty catastrophic. The security in bitcoin relies on the fact that it would be too difficult and expensive for an attacker to command 51% of the processing power in the network. A sudden switch to another hash function would significantly compromise security and likely cause the price to tank. But as I mentioned, Bitcoiners can rest easy because SHA-256 isn’t threatened by quantum computers (although that doesn’t mean someone won’t find a feasible attack in the future).
Back to ECDSA. This algorithm generates a public/private key pair. In Bitcoin, you keep the private key secret and use it sign your transactions, proving to the network that you own the bitcoins associated with a particular bitcoin address. The network verifies your signature by using the corresponding public key. A functioning quantum computer would allow the NSA to derive anyone’s private key from their public key. So do this mean that the NSA would be able to steal everyone’s bitcoins? Not exactly.
Here’s the thing, in Bitcoin your public key isn’t (initially) made public. While you share your Bitcoin address with others so that they can send you bitcoins, your Bitcoin address is only a hash of your public key, not the public key itself. What does that mean in English? A hash function is a one-way cryptographic function that takes an input and turns it into a cryptographic output. By one-way I mean that you can’t derive the input from the output. It’s kind of like encrypting something then losing the key. To demonstrate, let’s calculate the RIPEMD160 hash of “Hello World”.
Hello World ==> a830d7beb04eb7549ce990fb7dc962e499a27230
A Bitcoin address is calculated by running your public key through several hash functions as follows:
All of that is a complicated way of saying that while an attacker with a quantum computer could derive the private key from the public key, he couldn’t derive the public key from the Bitcoin address since the public key was run through multiple quantum-resistant one-way hash functions.
However, you do have to broadcast your public key to the network to make a transaction, otherwise there is no way to verify your signature. What this implies is that in the face of an NSA quantum computer all Bitcoin addresses would have to be considered one-time use addresses. Whenever you make a transaction you would have to send any excess bitcoin to a newly generated address as “change”. If you didn’t remove the entire balance from your address, the NSA could steal the remainder. While this is inconvenient, it would buy the developers enough time to swap out ECDSA for a quantum-resistant digital signature scheme.
Post-Quantum Digital Signatures
This section is going to be a little technical but hopefully not too difficult for beginners to follow. There are several different types of post-quantum public-key encryption systems: lattice-based, code-based, multivariate-quadratic, and hash-based. As I already mentioned, cryptographic hash functions are presumed to be quantum-resistant. Given that, it should be possible to build a replacement digital signature scheme for ECDSA using only hash functions. Let’s take a look at these hash-based systems since they are easy to understand and the hash functions they’re based on are already widely used.
Lamport One-Time Signature Scheme (LOTSS)
To begin, we’re going to want to use a hash function with at least a 160-bit output to provide adequate security. RIPEMD160 or SHA-1 should work. To generate the public/private key pair, we’ll start by generating 160 pairs of random numbers (320 numbers total). This set of random numbers will serve as the private key.
Pair# | Private Key |
---|---|
1 | e9e515b332cf1ce01299497e9e94b7df353ff022 ce56dcfdb7038e6ab0b37c383dbfda8cb45d60ea |
2 | 811f71c5cf7639a40df7b9b187bf768016791cf8 1094b13455a133d2d11898cfa30916e12be3e0ab |
… | … |
159 | bc6a1eb98148850dd2b32ae632005f5472c06a70 c10f4ac3d645d891d9b5dc0fa0b7294ad14ac3df |
160 | 585801c9da7ce0d562f375338b456ba9f10be3f6 3c3363ed7273f1ef9c1aed3fc5a7433002b668f8 |
To generate the public key we’ll take the RIPEMD160 hash of each of the 320 random numbers. (Note: I’m going to have to cut the numbers in half to fit them in this table)
Pair# | Private Key | Public Key |
---|---|---|
1 | e9e515b332cf1ce01299 ce56dcfdb7038e6ab0b3 |
d7c3e127380fbbbe37b9 4ddf29fb200aa0fd90b1 |
2 | 811f71c5cf7639a40df7 1094b13455a133d2d118 |
f84a8e5a0dce682e48c5 4a88310f694329b9ab97 |
… | … | … |
159 | bc6a1eb98148850dd2b3 c10f4ac3d645d891d9b5 |
7d5c0e19c4dc9077be6c ffbbe97612e581f073b6 |
160 | 585801c9da7ce0d562f3 3c3363ed7273f1ef9c1a |
38ed36c30ee72c95c598 a546f885e8210c61767d |
Now to sign a message with a Lamport signature we’ll first create a message digest by hashing the message with RIPEMD160 (in Bitcoin we would hash the transaction) then converting the output to binary. We’ll once again use “Hello World” as an example.
Hello World ==> a830d7beb04eb7549ce990fb7dc962e499a27230 ==> 1010100000110000110101111011111010110000010011101011011101010100100111001110100110010000111110110111110111001001011000101110010010011001101000100111001000110000
Next, we’ll match up each binary digit with each pair in our private key. If the bit is 0 we will add the first number in the pair to our signature, if it is 1 we’ll add the second.
Pair# | Digest | Private Key | Signature |
---|---|---|---|
1 | 1 | e9e515b332cf1ce01299 ce56dcfdb7038e6ab0b3 |
ce56dcfdb7038e6ab0b3 |
2 | 0 | 811f71c5cf7639a40df7 1094b13455a133d2d118 |
811f71c5cf7639a40df7 |
… | … | … | … |
159 | 0 | bc6a1eb98148850dd2b3 c10f4ac3d645d891d9b5 |
bc6a1eb98148850dd2b3 |
160 | 0 | 585801c9da7ce0d562f3 3c3363ed7273f1ef9c1a |
585801c9da7ce0d562f3 |
Finally to verify the signature is valid, you’ll first create a message digest using the same process as above. Then hash each of the 160 numbers in the signature with RIPEMD160. Finally, check to make sure these hashes match the hashes in the public key that correspond with the message digest.
Pair# | Hash of Signature | Digest | Public Key |
---|---|---|---|
1 | 4ddf29fb200aa0fd90b1 | 1 | d7c3e127380fbbbe37b9 4ddf29fb200aa0fd90b1 |
2 | f84a8e5a0dce682e48c5 | 0 | f84a8e5a0dce682e48c5 4a88310f694329b9ab97 |
… | … | … | … |
159 | 7d5c0e19c4dc9077be6c | 0 | 7d5c0e19c4dc9077be6c ffbbe97612e581f073b6 |
160 | 38ed36c30ee72c95c598 | 0 | 38ed36c30ee72c95c598 a546f885e8210c61767d |
So there you have it, a quantum-resistant digital signature scheme using only hash functions. Only the person in possession of the 320 random numbers in the private key could have generated a signature that hashes to the public key when compared to the digest. However, while his scheme does in fact work, it isn’t without problems. First, as the name suggests, LOTSS signatures can only be used once. The reason for this is because you are essentially releasing half of your private key with each signature. If you were to sign multiple messages, your private key would be completely compromised. If this were used in Bitcoin, you still could only use each Bitcoin address once.
Equally problematic, the key sizes and signatures are ridiculously large. The private and public keys are 6,400 bytes compared to 32 and 64 for the ECDSA private and public keys. And the signature is 3,200 bytes compared to 71-73 bytes. Bitcoin already has issues with scalability, increasing the key and signature sizes by that much would make the problems much worse.
The Lamport private key can be dramatically reduced in size by generating the random numbers from a single random seed. To do this you would just take RIPEMD160(seed + n) where n starts at 1 and gets incremented to 320. Unfortunately, the size of the private key isn’t so much the problem as is the size of the public key and signature. There is another one-time signature scheme called Winternitz signatures that has the potential to reduce key size but at the cost of hash operations. Fortunately, we aren’t done yet.
Merkle-Signature Scheme (MSS)
The Merkle Signature Scheme combines the one-time signature scheme (either Lamport or Winternitz) with a Merkle tree (also called a hash tree). This allows us to use one public key to sign many messages without worrying about compromising security. Let’s see how this works.
We’ll start by generating a number of Lamport key pairs. The number we’ll generate will be equal to the number of signatures we want to get out of a single public key. Let’s just say eight as an example. Next we’ll calculate a Merkle tree using each of the eight Lamport public keys. To do this, the public keys are paired together, hashed, then the hashes are concatenated together and hashed again. This process is repeated until something looking like an NCAA Tournament bracket is formed.
The hash at the very top of the tree (the Merkle root) is the Merkle public key. This massively reduces the public key size from 6,400 bytes in the Lamport signature to only 20 bytes, the length of a single RIPEMD160 hash.
To calculate a signature, you select one of your Lamport key pairs and sign the message digest just like before. This time, the signature will be the Lamport signature plus each one of leafs in the Merkle tree leading from the public key to the root.
In the above diagram the signature would be:
sig′||H(Y[i=2])||A[0]||auth[0]||A[1]||auth[1]||A[2]||auth[2]||A[3]
To verify the Merkle signature one would just verify the Lamport signature, then check to make sure the leafs hash to the Merkle public key. If so, the signature is valid.
There are several advantages of the MSS over LOTSS. First, the public and private keys are reduced to 20 bytes from 6,400 bytes. Also, you can create multiple signatures per public key. But there is still a major draw back. The more messages you want to sign with your public key, the larger the Merkle tree needs to be. The larger the tree, the larger the signature. Eventually the signature starts to become impractically large, especially for use in Bitcoin. This leads us to the final post-quantum signature schemes we’ll discuss.
CMSS And GMSS
MSS has been known for over 30 years and has remained essentially unscathed despite extensive cryptanalysis. However, most of the improvements to it have come in the last five years or so. In my brief survey of the literature, it seems a couple signature schemes by Buchmann, Dahmen, Klintsevich, et. al., are the most promising of the lot. These are the Improve Merkle Signature Scheme (CMSS) and Generalized Merkle Signature Scheme (GMSS) (Links to the academic papers can be found here and here). Two of the cryptographers behind this signature scheme are authors of a textbook on post-quantum cryptography.
Both CMSS and GMSS offer substantially improved signature capacity with reasonable signature lengths and verification times. GMSS in particular offers virtually unlimited signature capacity at 2^{80} signatures but with slower performance in others areas compared to CMSS. They accomplishes this by breaking the system up into separate Merkle trees of 2^{n} leafs. A signature from the root tree is used to sign the public key of the tree below it which signs the tree below it and so on.
So it seems to me that either of these signature schemes would be a serious candidate to replace Bitcoin’s ECDSA in a post-quantum world. But why not just go ahead and implement it now and rather than wait until the NSA springs a surprise on us? Let’s do a little comparison and take a look at the time (t) and memory (m) requirements for each. CMSS variants have signature capacities of 2^{20}, 2^{30}, and 2^{40} while GMSS has signature capacities of 2^{40} and 2^{80}. I would assume that 2^{40} if not 2^{30} would be plenty for Bitcoin as I can’t imagine someone would make more than a billion or trillion transactions from a single address. Also, GMSS can be optimized for faster verification times but at the expense of a 25% larger signature.
^{m}PrivKey | ^{m}PubKey | ^{m}Sig | ^{t}Keygen | ^{t}Sign | ^{t}Verify | |
---|---|---|---|---|---|---|
ECDSA | 32 bytes |
64 bytes | 71-73 bytes | 9.6 ms | 100 ms | 8.53 ms |
CMSS20 | 1900 bytes | 46 bytes | 2128 bytes | 4.1 sec | 12.5 ms | 2.0 ms |
CMSS30 | 2788 bytes | 46 bytes | 2328 bytes | 2 mins | 17.0 ms | 2.0 ms |
CMSS40 | 3668 bytes | 46 bytes | 2528 bytes | 62.3 mins | 21.7 ms | 2.0 ms |
GMSS40 | 1640 bytes | 20 bytes | 1860 bytes | 723 mins | 26.0 ms | 19.6 ms |
GMSS40′ | 1680 bytes | 20 bytes | 2340 bytes | 390 mins | 10.7 ms | 10.7 ms |
So from the table we can see that CMSS and GMSS actually perform better than ECDSA in public key size and signature time. However, in the critical variable that will affect scalability, signature size, they don’t perform nearly as well. Verification time for CMSS is actually better than ECDSA which would actually improve scalability and the optimized variant of GMSS is relatively close, but signature size for both would definitely be an issue. Consider some very rough estimates: the average transactions size is currently about 500 bytes, either CMSS or GMSS would push it up over 4000 bytes. That means you could be looking at an increase in the size of the block chain of upwards of 700%. The block chain is currently at 12.7 gigabytes. Had Bitcoin employed either of these signature schemes from the beginning, it would be over 100 gigabytes right now. Signature and key size isn’t a problem that is unique to hash-based signature schemes either, most of the others are in the same ballpark.
Also, note the insane keygen time for GMSS. If you left your computer running for 24 straight hours you would have only generated 3 bitcoin address and that’s using the optimized variant with larger signatures! I suspect, however, that an ASIC hardware wallet would significantly improve that performance. Keygen for CMSS isn’t that bad.
So in other words, Bitcoin can’t adopt one of these signature schemes at the moment if we want to scale beyond present capacity. However, by the time quantum computers become viable, Moore’s law will likely have brought the cost of storage and processing power down to the point where CMSS, GMSS or one of the other types of post-quantum signature schemes could easily be merged into Bitcoin. Until then, let’s not lose any sleep over Penetrating Hard Targets.
Original content by Chris, copyleft, tips welcome