Data Encryption: How Encryption Works Part II

Data Encryption: How Encryption Works Part II

How Encryption Works

In our previous blog, we discussed the history of encryption and the way it has evolved. In this blog, we’ll talk a bit about how such encryption is applied in web technologies we’re familiar with, how encryption works, and what the future holds for encryption algorithms.

What is HTTPS and SSL/TLS?

If you recall, in our last blog, we touched on the Diffie-Helman method of using two keys – one to encrypt and the other to decrypt.

In a practical application of asymmetric key encryption between 2 parties, the Diffie-Helman mechanism requires an exchange of public keys between the 2 entities – so they can encrypt messages meant for the other or decrypt messages sent by the other.

A practical implementation of Diffie-Helman was made possible by 3 MIT scientists – Rivest, Shamir, and Adleman in 1977, the very next year after Diffie and Hellman made their theory public.  Popularly known as RSA, this practical implementation of Diffie Helman used mathematical factoring as the way to create the one-way function that is essential as part of the Diffie-Helman key exchange.

In real-world scenarios using asymmetric encryption for transmission of all data would be frustratingly slow.  So, asymmetric encryption is usually used to exchange a symmetric key confidentially between both sides – which is then used to encrypt the actual data payload.

The mechanism of this initial handshake, exchanging public keys, deciding on a confidential, common, symmetric key, and transmitting data encrypted in flight is called SSL (Secure Sockets Layer), also known as TLS (Transport Layer Security).  SSL was originally invented by Netscape and then handed over to the Internet Engineering Task Force (IETF).   HTTPS is the protocol that SSL rides on.

What is SSL certificate how does it work?

One risk with Diffie-Helman is that an intermediary can intercept the public keys during the initial exchange and substitute them with their own public keys thus fooling the endpoints into believing they’re communicating with each other when in reality, all communications are being hijacked by an actor in between.  This is commonly called a Man-In-The-Middle attack (MITM) and is the reason we use certificates today.  A Certificate is a way to authoritatively attribute ownership of a public key to an entity or individual.  Certificates are typically issued by trusted sources called Certificate Authorities and are protected dearly.  This is why, when you are using a browser with an HTTPS URL, you may sometimes see a warning that the site may not be trustworthy.  This usually means that the certificate being used by the site isn’t from a valid CA and that it could be vulnerable to a MITM attack.

Quantum Computing and Quantum Resistant Encryption

While classical computers carry out logical operations using the definite position

of a physical state (0 or 1), quantum computers perform calculations based on the probability of an object’s state before it is measured – instead of just 1s or 0s – which means they have the potential to process exponentially more data compared to classical computers.

While quantum computing is still in its infancy, it is a fact that mathematical problems which are considered computationally “too intensive” for today’s computers may not be so for quantum computers.  Should that happen, the defensibility of today’s encryption algorithms could disappear or be seriously compromised.

Not surprisingly, asymmetric encryption algorithms (which are weaker and less defensible computationally) are likely to be the main casualties of quantum computing.  But, work is already underway to build more quantum-resistant versions of asymmetric encryption.

Symmetric encryption will not be impacted nearly as much by quantum computing.  While quantum computing is likely to take a bite out of symmetric encryption algorithms, increasing the key size will again give symmetric encryption enough runway and defensibility.

Key Management and Segregation of Duties

A small thought to end the blog with… remember that your encryption is only as good as how well your keys are protected.  Many times, when you place data on the cloud (aka someone else’s computer), you need to be sure that the data is safe.  Most cloud/SaaS vendors will claim to encrypt the data you put there in order to make you feel safe, but you should know that you really have no control over the encryption process or the keys used in that process.

Best practice encryption always requires a separation of duties between the owner of the data and the cloud or SaaS vendor.  This means you should control the encryption and the keys and let the cloud or SaaS vendor manage the data.

Strong encryption without separation of duties is as good as no encryption.  You can technically argue the data is secure, but since it can be decrypted by others you haven’t authorized, it is not private.

Encryption will be an important key (no pun intended) to the future of computing.  Knowing how encryption works will put you in a position of advantage and let you have more control over your data assets.  Parablu’s solutions rely on strong encryption with strict enforcement of separation of duties and are designed to keep your data safe.  Write us at to learn more.

Do you have specific requirements or enterprise needs?

Share the Post:
Scroll to Top