Introduction
I started writing this post thinking that I'd make it a bit of a brain dump of my recent decision to buy a hardware wallet. It quickly morphed into a somewhat more in-depth discussion of asymmetric cryptography so I decided to break the post into parts. This is part 1.
Credit
Before moving on I want to give massive credit to "Plany" on blogs.msdn.microsoft.com for the Crypto Primer video found here as this is what the information below is based on with annotations from me.
Motivation
I'd not heard of KeepKey prior the two comprehensive posts made by
about a month ago here and here. Since then, the idea of getting one for myself has been floating around in my head almost continuously. Many here however may not yet be quite sure about what hardware wallets are, what they have to do with private keys and why they're something worth considering so let's back up a little...
securestate.com
Crypto Primer
It all at the end of the day comes down to the importance of protecting your private keys. Private keys are essentially just numbers. They're one half of a pair of numbers actually which you've probably heard of, the other referred to as the public key. These two numbers together form the backbone of how Public Key Cryptography works. These two numbers share an interesting property, that being that information encrypted with one of the numbers can only be decrypted with the other. That's why the scheme is often referred to a asymmetric cryptography. It actually doesn't matter which key is used for the encryption and which for the decryption (and hence which is public and which is private) but for simplicity sake we pick one, call it private and from there forward keep it that way.
Signing is the act of applying a cryptographic algorithm using a private key. The act of decrypting that message successfully with the corresponding public key hence provides authentication (if a message was able to be decrypted with a public key then the claimed owner of the private key must have genuinely encrypted it). This is the process by which the X509 PKI system works. It's all very seamless and neat but can cause a great degree of confusion. At the end of the day all you need to know really is that the private key is used for "locking" a secret and the public key is used for "unlocking" a secret and visa versa. Use the wrong key to unlock a secret and you don't get very far. Importantly, if I used my private key to encrypt a secret and try to claim that the secret is from you, when someone decrypts the message with your public key (as they would if they think the message is from you) they'll get rubbish as my private key's unrelated to your public key. Only your private key and public key are related.
Clear as mud?
For those who are interested in more detail, I highly recommend this walk through video which is the best explanation of cryptography and digital signatures I've come across in my career to date and I'll borrow a few points from it here to summarize for those who find it a bit too deep.
Public Private Key Algorithm Mathematics
Around 1976, three mathematicians named Ron Rivest, Adi Shamir and Leonard Adelman invented (or rather reinvented what Clifford Cocks at GCHQ had come up with secretly about 3 years earlier) the PKI algorithm. The three went on to founder the security company RSA.
Rivest, Shamir & Adelman thanks to ams.org
Let's look at an example. First a public key is generated. We pick 2 random giant prime numbers. Let's start small for simplicity. p = 17 and q = 11. p and q here simply designate the numbers, they don't mean anything semantically. Let's multiply them together to get 187. We then pick a second prime number, e = 7 say. That's our public key, comprised of two numbers. Now we use the public key to generate the private key (and keep in mind that none of this is exposed to the user really, this is for interest's sake). We run it through the algorithm using modular arithmetic . With a private key represented by d we have
e * d = 1(mod(p-1)*(q-1))
7 * d = 1(mod 16 * 10)
7 * d = 1(mod 160)
d = 23 (the private key in this example)
So let's send a message! Let's send a single character to keep things simple. Let's send x which in ASCII is 88. In this example we are sending a message using someone else's key pair and hence we only know the public key's two numbers, remember these are n = 187 and e = 7. The recipient of our message will use their matching private key (which we obviously don't know) to decrypt our cheeky little x message. Running our message 88 through the simple algorithm that follows produces our cipher-text
cipher-text = 88^e (mod n)
cipher-text = 88^7 (mod 187)
cipher-text = 11
We send 11 as our encrypted data.
The other end has the private key which in our example is d = 23so it uses that to decrypt as follows
plain-text = cipher-text ^ d (mod n)
plain-text = 11 ^ 23 (mod 187)
plain-text = 88
In reality, the prime numbers involved are massive.
Crypto Primer TLDR; Summary
- In cryptography, it's not the encryption algorithm that's kept secret. It's the keys (particular numbers) that are used in the algorithm.
- Further more, a good encryption algorithm means that even if the algorithm and the cipher text itself are known, the plain text data is still kept secret. Sounds odd right? Given the answer and the equation, you'd think you could quickly get the input?
x + 5 = 20, you'd figure out x to be 15 without much drama, right? - Crypto algorithms use special "one way functions" that prohibit the above, that is it's not possible to get to the input value knowing the output value.
- There are two main types of algorithms, symmetrical and asymmetrical (that I mentioned above). Symmetric algorithms use the same key for both encryption and decryption. Asymmetric algorithms (such as public-private key cryptography) use one key for encryption and a different (yet mathematically related) key for decryption.
- The strength of public private key encryption lays in the fact that mathematically there is no pattern to a series of prime numbers other than that they're prime and so they are unable to be predicted via an algorithm (yet!)
- Encryption has two inputs, plain text and the key. It as one output, cipher text. Decryption has two inputs, cipher text and the key. It has one output, plain text.
- Modular arithmetic gives us a means of implementing one way functions for cryptography. A simple example is that if you add 5 hours to 9am on a clock face, you get 2pm. Written down this would look like
9 + 5 = 2This is an example of modular arithmetic where the modulus is 12 so we could also write9 + 5 = 2 (mod 12). The key here is that there's no way to know what the starting time was given that you know the answer, right? If I said I finished writing this Steemit post at 2pm, and it took 5 hours, you only know what time I started because you know that there are 12 hours on a clock face. 24hr time is an example without the mod operation. - Modular arithmetic gives a function a wonderful property, unpredictability.
- Key pairs are generated together as they are mathematically related. The public key is broadcast such that anyone can use it to decrypt messages that you encrypt. The private key is kept secret.
- This process works for bidirectional traffic too. Someone wanting to send a message to you encrypts it with your public key which everyone has and can be guaranteed that only you can decrypt it with your private key. This is where the mathematical relationship between the keys comes into play. Whether it's encryption or decryption, only you can form one side of the transaction with your private key for either inbound or outbound data.
- In reality, many web servers will go as far as using special tamper resistant hardware stores for protecting private SSL keys (starting to sound a little like a crypto hardware wallet?)
Conclusion
Hopefully this post has helped to demystify the nature of public private key encryption and it is a stepping stone towards imparting the importance of keeping private keys safe in something like a hardware wallet. I've really only scratched the surface here. That later part I'll address in a subsequent post.