When I was an undergrad student in college, we tried to work on a project with the core implementation of RSA cryptography – An email encryption app. I studied how RSA worked and implemented it for the email encryption system. I also encrypted the message with the receiver's public key, and the receiver decrypted the message with their private key.
According to Wikipedia, RSA (Rivest–Shamir–Adleman) is a public-key cryptosystem widely used for secure data transmission. Since HTTPS also used the RSA algorithm, I thought that's how they do their encryption, but I was wrong. Well, not completely.
Asymmetric, or public-key cryptography, is a cryptographic system that uses two mathematically related keys – A public key and a private key. The keys secure data transmission and communication over a public network like the Internet.
In this system, each user has a pair of keys, one public and one private. The public key is used to encrypt messages, is widely distributed and can be freely shared with anyone. And the private key is used to decrypt messages, kept secret and known only to the owner.
When someone wants to send a secure message to the public key owner, they use the public key to encrypt the message, which can only be decrypted using the corresponding private key. This ensures that only the intended recipient, who has access to the private key, can decrypt and read the message.
Public-key cryptography is used for a variety of purposes, including:
- Secure communication over the Internet: HTTPS, SSL, and TLS protocols use public-key cryptography to encrypt data during transmission.
- Digital signatures: A sender can use their private key to sign a message, and anyone with access to their public key can verify that the message was not tampered with and was indeed sent by the sender.
- Key exchange: Public-key cryptography can be used to securely exchange keys for symmetric-key cryptography, which is faster and more efficient than public-key cryptography for encrypting large amounts of data.
RSA and Elliptic Curve Cryptography (ECC) are the most used public-key cryptography algorithms.
Amongst all this, RSA uses a complex encryption-decryption system compared to some symmetric encryption processes.
When I worked on my project, I only used RSA for encryption-decryption, and it was the right choice since I only encrypted the mail once and was done with it. However, connecting to a server and working with various requests and responses with huge amounts of data is a whole new ordeal.
The RSA security uses the product of two large prime numbers. This complexity is referred to as the factoring problem. Since RSA is a relatively slow algorithm compared to other symmetric algorithms, it isn't widely used to directly encrypt user data. Rather RSA uses 'a shared key' for symmetric-key cryptography to encrypt large data.
Using RSA in every process of such web surfing would result in heavy processing. Therefore, HTTPS uses RSA at first to establish an agreed-upon shared key and then follows the symmetric cryptographic process for other requests and responses.
HTTPS Encryption Process
Let's go over the HTTPS encryption process by outlining its key steps.
1. Initiate the connection
- The client browser initiates the connection with the server. It is a non-encrypted plain connection.
2. The server gives its public key
- After the server receives the request for initiation from the client, it sends its public key back to the client.
3. Generation of the session key by browser
- After the client receives the server's public key, it generates a session key to be sent to the server.
4. Send the session key to the server
- The session key is then encrypted by the server's public key. After encryption, the client gives the encrypted session key to the server.
5. The server gets the session key
- After receiving the client's encrypted session key, it decrypts it using its private key. Thus, it retrieves the session key from the client.
6. Symmetric encrypted messaging starts
- After successfully sharing the session key, the client acknowledges establishing the secure connection, and further encryption/decryption of messages is symmetrical, based on the shared session key.
Why Does HTTPS Not Use An Asymmetric Cryptographic Process?
The reason why HTTPS doesn't use the asymmetric cryptographic process all the way through is:
- Asymmetric encryption with each other's public key is heavy and resource-hungry compared to symmetric encryption.
- Since the shared key is symmetric, it is a speedy process.
- Since the shared key is shared by asymmetric encryption, it is secure. Only the client and server know the secret keys.
When I discovered how HTTPS worked, though it doesn't use asymmetric keys throughout the process, I was relieved to know it was secure and a fine approach.
Subscribe to our DevBlog with the buttons below to stay updated.