Introduction

On the Internet, we try to send data between two nodes, users, or machines, but there is always an underlying threat of information or data leaks, generally termed as Man-in-the-Middle attack.

Thus, cryptography comes into the picture.

Exploring Cryptography Step by Step

To understand this better, let's consider a scenario where user A is sending a message to user B, and a hacker is acting as the Man-in-the-Middle trying to intercept the message. We'll break down the process into stages, demonstrating how security can be increased at each stage.

Initial Communication

User A sends the message stating "I love you" to user B. As there is no security in place, the hacker intercepts the data, changes it to "I hate you," and sends it to user B with the identity of user A. In this step, the hacker can read and manipulate the message.
Basic Encryption

💡

Encryption is the process of converting plain text into ciphertext using cryptographic algorithms and keys. It ensures that sensitive information remains secure during transmission or storage by scrambling the data into an unreadable format for unauthorized parties. Decryption, on the other hand, reverses this process, converting ciphertext back into its original plain text using the decryption key.

To mitigate this issue, we need to encrypt the data. User A encrypts the message and sends it to user B. Here, the hacker can intercept the encrypted data but cannot de-cipher its contents due to the encryption. However, the hacker can still tamper with the encrypted message and send a modified version to user B. The hacker may delete the original message from user A and impersonate them by sending messages to user B using their identity.

While encryption prevents the hacker from reading the plaintext directly, it's crucial to use strong encryption methods and secure key management practices to safeguard against manipulation and unauthorized access to sensitive data.
Asymmetric Encryption

The main problem with encryption lies in securely sharing the encryption key over the same insecure network. This issue leads to the concept of asymmetric keys.

💡

Unlike symmetric encryption, which has only one key, asymmetric encryption involves two keys for each user: a public key and a private key. The public key encrypts the data, which can only be decrypted by the corresponding private key and vice versa decryption and encryption are also possible. The public key is accessible to anyone, while the private key remains securely with the user.

Here's how it works: when user A wants to send data to user B, they encrypt the data using B's public key. Only user B, with their private key, can decrypt and access the original data.

This asymmetric encryption approach enhances security by allowing users to communicate securely over insecure networks without needing to share a secret key directly. Instead, they share their public keys.

In this step, we effectively prevent the hacker from reading the data sent by user A, similar to the previous step. However, the hacker can still manipulate user A's data and use the Identity of user A when sending messages to user B.

💡

There are algorithms to create asymmetric keys. For public keys, we can use AES (Advanced Encryption Standard) and DES (Data Encryption Standard), while for private keys, algorithms like RSA (Rivest, Shamir, Adleman) and ECC (Elliptic Curve Cryptography) can be utilized. Some algorithms prioritize security, while others emphasize speed, depending on the use case. In computer science, algorithm choices always involve trade-offs.
Digital Signatures

To prevent a hacker from using the identity of user A and manipulating the message, we use digital signatures as a solution.

User A will encrypt the data with their own private key and send it to user B. User B will then decrypt the message using user A's public key. This way, even if the hacker intercepts and manipulates the message, user B will be unable to decrypt the altered message, ensuring that the hacker cannot use the Identity of user A.

However, this approach has a drawback. Although the hacker cannot steal user A's identity, they can still decrypt user A's message and read it, posing a threat to the privacy of the users.
Saving Privacy

To address the drawback of the previous step and prevent the hacker from using the identity of user A, we use digital signatures with a double encryption method. The procedure is as follows:

First, the message is signed with user A's private key (1st round of encryption). Then, the encrypted message is signed again with user B's public key (2nd round of encryption). When user B receives the message, they will first decrypt it using user A's public key (1st round of decryption), and then decrypt it again using their own private key (2nd round of decryption).

If a hacker tries to intercept the message, they may be able to remove the first round of encryption using user A's public key, but they can't break the second round of encryption because user B's private key is not publicly accessible. This ensures that the hacker cannot read the data or use user A's identity. Even if the hacker tries to delete the message and send raw or some sort of encrypted data, user B will not be able to decrypt it correctly, thus preventing the hacker from using user A's identity.

Sounds like a perfect solution, right? But here's the catch: there's still a vulnerability. When sharing user B's public key to encrypt the data, the hacker can act as a proxy, deleting the incoming public key of user B and swapping it with the hacker's public key. Then, user A would sign the data with the hacker's public key. When user A sends the data to user B, the hacker intercepts and decrypts it with user A's public key and their own private key, modifies the data, encrypts it with user B's public key, and their own private key, and then sends their public key pretending it is user A's public key. In this way, the hacker can read, manipulate the data, and steal the identity of user A.

It seems like we're back to the starting point—umm, not really. Now, let's make the hacker's life tougher by using SSL certificates.
SSL Encryption

To solve the above problem, we use SSL certificates (Secure Socket Layer) to verify users. These certificates are typically issued by third-party services like Let's Encrypt. They create a certificate containing the user's public key (user B's) and the service provider's public key.

When user B sends their public key and SSL certificate to user A (the sender), user A fetches the data from the certificate provider (Let's Encrypt) and obtains Let's Encrypt's public key. User A then verifies whether Let's Encrypt's public key and User B's public key form the same signature. If they match, we can confirm that the public key is genuinely from user B and not from a hacker. User A then encrypts the message with his private key (user A's) and user B's public key and sends it to user B. User B decrypts the message with their private key and user A's public key.

Now, let's see how the hacker tries to intercept and manipulate the message and how SSL certificates thwart this attempt.

Initially, the hacker intercepts the communication between user A and user B and attempts to replace user B's public key with their own public key. The hacker sends their own public key along with a fraudulent certificate or the same certificate (decryption fails in both cases) to user A. User A receives the hacker's public key and the fraudulent certificate.

User A then contacts Let's Encrypt to fetch the real public key of Let's Encrypt. User A uses Let's Encrypt's public key to verify the signature on the received certificate. The verification fails because the fraudulent certificate does not match Let's Encrypt's signature. User A detects the mismatch and realizes that the public key is not from user B but from the hacker.

Consequently, user A discards the fraudulent certificate and does not proceed with the communication. The hacker's attempt to intercept and manipulate the message is thwarted because the SSL certificate verification failed.

By implementing SSL certificates, we ensure that the public keys exchanged between users are authentic and have not been tampered with by a hacker. This prevents the hacker from intercepting and manipulating messages and the identity of the user, thereby maintaining the security and integrity of the communication.

You might be wondering if we need to go through this verification process for every message. The answer is no. As indicated by the name Secure Socket Layer (SSL), once we verify the keys and user identity during the initial socket connection, a secure channel is established. This 'pipe' ensures no further intervention is needed for secure communication.

Thus, as the encryption keys are exposed, you might think they could be easily decrypted. However, that's not the case. These keys are mostly 256 bits long, which means breaking them would require 2 ^ 256 possibilities. This is nearly equal to 2×10 ^ 77 possible outputs, making it extremely difficult to decrypt unless you are incredibly lucky to guess the correct key on the first try. Trying all the possibilities is very challenging, even with supercomputers.

According to Moore's Law, "the number of transistors in an integrated circuit (IC) doubles approximately every two years." Consequently, computer scientists continuously work to make encryption stronger over time to stay ahead of increasing computational power.

Applications

Communication between two users or between a user and a server: Ensures secure and private data exchange.
GitHub commit signing: Verifies that a commit came from the repository owner or an authorized committer, ensuring the integrity of the codebase.
Single Sign-On (SSO): Allows users to securely authenticate with multiple applications and websites by using just one set of credentials.
Email encryption: Services like PGP (Pretty Good Privacy) and S/MIME (Secure/Multipurpose Internet Mail Extensions) use encryption to protect email content from being read by unauthorized parties.
Secure online transactions: E-commerce sites and online banking platforms use encryption to protect sensitive information like credit card details and personal data during transactions.

Final Thoughts

We've explored the importance of cryptography in securing digital communication. From basic encryption to advanced methods like asymmetric encryption and SSL certificates, each step enhances data security and integrity. Understanding and implementing these concepts help protect sensitive information from malicious attacks, ensuring safe and private online interactions. As technology advances, the need for robust security measures grows, making cryptography a much stronger and more reliable tool for securing our data in the digital world.

Resources

Let's Encrypt's blog - Provides information about SSL certificates and related topics.
Wikipedia page on cryptanalysis - Discusses the mathematical perspective behind cryptography (I love Maths✌️).
Encryption and public keys video onCode.org by Mia Epner - Offers an educational perspective on encryption and public key cryptography.

Cryptography and Digital Signatures

Table of contents