Menu
What does it take to communicate privately in peace? Lots of math and several decades of research.
As I mentioned before, cryptographic hash functions and asymmetric encryption are the foundation of blockchain. We have spent time looking at what cryptographic hash functions are. Then, we examined the workings of the popular SHA-256 cryptographic hash function. Now, it's time to look at asymmetric encryption.
Encryption scrambles a message so that only certain people can read it. It ingests messages and outputs seemingly unrelated ciphertexts, like cryptographic hash functions. However, encryption produces cyphertexts of variable length, and the process is reversible. In other words, the ciphertexts are not fixed-length, and you can get the message from a ciphertext. We use encryption keys for both encryption and decryption. The keys are pieces of information that are used with a cipher (i.e., an encryption or decryption algorithm) to move between the message and ciphertext spaces.
There are two broad categories of encryption: symmetric and asymmetric. Symmetric encryption uses the same key and cipher for encryption and decryption. That means that the person originating the message (e.g., Jane) and the intended recipient (e.g., John) must agree on the cipher and key. In other words, Jane and John must agree on a cipher to use, and then Jane will generate a key for use with that cipher. Afterward, Jane must securely transmit the key to John. Only then can they communicate securely using that key.
Asymmetric encryption is relatively slow.
Asymmetric encryption (a.k.a., public key-private key encryption) uses different keys for the encryption and decryption process. If Jane and John were to use asymmetric encryption, both Jane and John would have to generate an encryption key and decryption key. They keep their encryption keys secret and exchange their decryption keys. So, when Jane wants to message John, she encrypts her message with her encryption key and transmits the ciphertext to John. John then decrypts the ciphertext with Jane’s decryption key. To respond, John encrypts his response with his encryption key.
Symmetric encryption is usually better for bulk encryptions since they typically have smaller key sizes. So, the encrypted message takes up less space and can be transmitted faster. The major drawback of symmetric encryption is the exchanging of keys. Jane and John cannot assume secured communications if the key gets intercepted. So how can Jane and John exchange keys securely? They can meet in person and physically hand the key to each other. That is not always feasible, however. What if they live on different continents? Also, what if Jane wants to communicate with another person (e.g., Sarah)? She would have to generate and exchange another key with Sarah. Then, Jane would have to keep track of which key to use when sending to John or Sarah. Jane has to worry about key management and exchange. Replacing compromised keys further complicates key management.
The search for a solution to those problems led to asymmetric key encryption. Decryption (i.e., public) keys can be made public without compromising security. So, after Jane generates her keys, she can make her decryption key public. Therefore, when John or Sarah receives a message from Jane, they can grab her public key and decrypt the message. When either John or Sarah wants to message Jane, they encrypt their communication with her public key and send it off. As a result, Jane does not have to worry about securely exchanging or managing multiple keys. Additionally, John and Sarah know that the encrypted messages are from Jane. After all, only she has the encryption (i.e., private) key.
Given asymmetric encryption's advantages, why do we still use symmetric encryption? Well, asymmetric encryption is relatively slow. So, we typically use it to exchange symmetric encryption keys. Then, we use symmetric encryption to exchange further messages. So we have the best of both worlds. SSL/TLS takes this approach with the SSL Handshake.
When you connect to a website over HTTPS, your browser sends your supported SSL/TLS versions and cipher suites to the server. A cipher suite is a set of encryption algorithms used in establishing secure communications, listed in order of preference. The server responds with its chosen SSL/TLS version, cipher suite algorithm, and SSL certificate that has its public key. Your browser validates all signatures on the certificate and verifies the server's identity. Then your browser sends a premaster key encrypted with the server’s public key. A premaster key is a random byte string used to compute a symmetric key. That is the key used to encrypt and decrypt all future messages.
That is asymmetric encryption in a nutshell. Next time, we'll look at the algorithm that started it: RSA.