Encryption might sound like something that only your IT team obsess about, but in reality, you come into contact with multiple forms of encryption software every single day. In fact, when you think about it, encryption has been around for a very - very - long time.
Protecting messages by encoding their contents, so that only authorised parties can understand them, is hardly from a new concept - but today, certainly from an IT perspective, it has become increasingly complex. For the vast majority of non-technical people, it is also something of an unknown.
As part of our recent lunchtime TechBytes, where we unpack software concepts for our non-engineering teammates, we shared a straight talking introduction to encryption and how, at a fundamental level, it actually works. In this post, I have provided a recap of that talk.
So what is encryption?
The mechanism is straightforward. A message, or ‘plaintext’, is transformed into an unintelligible sequence of characters - the ‘cyphertext’ - before it is sent. These characters can then be communicated via any public medium, such as the internet, without anyone being able to understand the plaintext message. At the receiving end, the cyphertext is transformed back into the original message by the intended receiver.
You can broadly classify encryption into two types:
1. Symmetric encryption
2. Asymmetric encryption
Symmetric encryption uses the same key for both encryption and decryption. It is most suitable for encrypting bigger messages because it doesn’t use a huge amount of computational power.
Before the mid 1970s, this was also the most common form of encryption used. Importantly, it required a central agency, such as a government, to hold an encryption key. So, if two secret agents wanted to communicate securely, they requested an encryption key from a central agency, using this key to both encrypt and decrypt messages.
The main disadvantage, however, of symmetric encryption done in this way is precisely the fact that you need a central agency to establish a common key. Let’s think about this from a Big Brother perspective. Say two members of the public wanted to communicate securely, and they request a common key from the government. They can securely read their messages, but then, so can the government - introducing a potential weak link in the encryption chain.
Way back when in 1976, two men, Whitfield Diffie and Martin Hellman, published an alternative - known as asymmetric key encryption.
Asymmetric encryption requires a pair of related keys to be generated: the public key, and the private key. With asymmetric encryption, whatever is encrypted using the private key can be decrypted using the public key - and vice versa. The private key is then kept as a secret by the party that generated the pair, while the public key can be distributed to the public.
This means that you no longer need a central authority to hold a common key. In essence, the private key acts like the central agency, but remains within the control of the party wanting to encrypt a message.
However, the downside to asymmetric encryption is that it uses a lot more computational power than symmetric encryption, and is therefore only used for encrypting short messages.
Having introduced both symmetric and asymmetric encryption, we now have our first tools for establishing secure communication. So let's consider an example from day-to-day use: a browser establishing the identity of a website.
Assume our browser tries to connect to Google.
It accesses the internet, and looks for the server google.com. When it finds it, Google sends its public key to the browser. In order to establish that it really is Google, the browser sends a message encrypted with Google's public key. If Google is able to echo the same message back, then the browser knows that it's the real Google - because only the private key could have decrypted that message.
After authenticating Google, asymmetrically encrypted communication follows. However, since it is computationally expensive to use the asymmetric approach, it is only used insofar as to exchange a common secret - this then forms the key for symmetric encryption. At this point, both the browser and Google can send longer messages to each other without paying much computational overhead.
Hang on, though - you might be thinking there’s a catch. What is to stop someone else claiming to be Google, and sending their own public key to the browser?
This is where certificates come in. A certificate ensures the browser that the public key that Google sends really does belong to Google. Trusted parties, called certificate authorities (or CAs for short), issue these certificates and the security of exchanges depends on the trustworthiness of the CAs.
These CAs make it their business to be trustworthy - literally. Certificates have expiry dates that are constantly updated to ensure their security. I’m sure most of us have experienced that pop up warning on a site that advises us when a certificate is out of date. If there is a known issue, certificates can be revoked, and a new certification is issued as and when it is needed.
1. Google sends a certificate containing its public key to your browser;
2. The browser verifies that the public key is authentic by checking the signature of the certificate;
3. A round of asymmetric encryption is used to establish a common key;
4. With the common key established, the rest of the communication is then done using symmetric encryption.
Encryption as a concept dates back thousands of years but as our communications and technology have become more sophisticated, our encryption methods have had to stay one step ahead. Today, digital security is has become an integral part of our lives - with encryption protecting everything from our banking details, to our social messages and mission critical business information hosted in the cloud. Hopefully, in this post, I have helped to demystify the process for those of us who rely on encryption but have seldom asked or understood how, from a technical point of view, it actually works.
If you have any questions, or want to learn more about encryption, get in touch with us here.
Photo courtesy of Christiaan Colen