By Austin Chamberlain, on 12 March 2017
We’ve talked about the theory of cryptography before; now I will describe some of the main uses of cryptography.
The most obvious use of cryptography, and the one that all of us use frequently, is encrypting communications between us and another system. This is most commonly used for communicating between a client program and a server. Examples are a web browser and web server, or email client and email server. When the internet was developed it was a small academic and government community, and misuse was rare. Most systems communicated in the clear (without encryption), so anyone who intercepted network traffic could capture communications and passwords. Modern switched networks make interception harder, but some cases – for example, public wifi – still allow it. To make the internet more secure, most communication protocols have adopted encryption. Many older protocols have been dropped in favour of newer, encrypted replacements.
The best example is web encryption, since here you can choose between a clear or encrypted version of a website by switching between HTTP and HTTPS in the URL. Most large companies now use the encrypted form by default, and you’ll see that any visit to Google, Facebook, Microsoft Office 365 or other sites will be to the HTTPS version of the site. This is accompanied in recent browsers by extra information, including a padlock to show that it is HTTPS. Something you can try is to click the padlock on an encrypted page, and your browser will tell you more about the page security. It will also tell you the especially relevant fact of the actual site name you’re visiting. Therefore, if you’re entering a password in a page, please do check that it is HTTPS.
Email is one area where encryption is not widely in use. When email moves from server to server, and from server to you, it is encrypted. On the mail server and on your system, however, an administrator can read it. There are options to implement “end-to-end” encryption for email (I use PGP) but email systems are complex and these options are complex. Truly secure messaging systems – where only the sender and receiver can read the message – are those where encryption has been built in from the start. Whatsapp is good; Signal is better.
We all store a large amount of data, and any data is valuable to at least the person who generated it. Every operating system uses encryption in some of the core components to keep passwords secret, conceal some parts of the system, and make sure that updates and patches are really from the maker of the system.
A more notable use of encryption is to encrypt the entire drive, and require correct credentials to access it. UCL has recently implemented Microsoft’s Bitlocker on Desktop@UCL machines, and this means that without the user logging in the data on the drive is completely opaque. If someone took the drive and tried to read it, they would not be able to access any data. This has the occasional side effect of locking the system, so some UCL readers may have had to request the recovery key.
One notable point is that many encrypted systems nonetheless allow administrators of the system access. Office 365, for example, uses encrypted communications, but many senior Microsoft staff, and a few UCL administrators, can access the data. A relatively recent development is software to create encrypted containers on a drive. I have recommended Veracrypt to some users who need to create an encrypted volume which is completely under their control.
In the last blog post I briefly introduced cryptographic hashing, a one-way mapping of a string to a fixed-length value. One of the main uses of this is to store passwords. It is very risky to store passwords in an accessible way. If stored in plaintext on a system, anyone who has access to the system – legitimate or malicious – can read the password. Encryption is only a partial answer to storing passwords. If someone has access to the system storing the encrypted passwords, they will probably have access to the encryption key to decrypt the password. Hashing, on the other hand, produces a relatively useless value for the attacker. A system will take the password on login, hash it, and compare to the hashed value. At no point will the system – or an attacker – have access to the plaintext password.
Cryptography is hard
The impression you might get from this is that encryption is difficult to implement properly. This is correct, unfortunately! I encourage everyone to use encryption more, and I’m always happy to give advice. If you have any questions, please contact the team.