The main use of symmetric encryption is to encrypt data so that only those who know the key can access the data. There are other, less well known uses too.
The most obvious application for symmetric encryption is transferring secret information between 2 people (or 2 computers) over an insecure channel - for instance by email, or on removable media.
The simple solution is for person A to encrypt the data with a secret key before it is sent. When person B receives the data, he can decrypt it using the same key to recover the original plaintext. If anyone else intercepts the ciphertext, it will be useless to them. The message remains secret, no matter who sees the ciphertext. The main problem here is that A and B need to have previously agreed on a secret key, and they both need to keep it secret. As we will see later there are better ways of doing this with public key encryption.
Another example is a "wallet" application. It is very useful to be able to store information on your laptop or mobile phone so you always have it to hand - membership numbers, insurance policy numbers, credit card details, PIN’s, passwords. Of course it would be a disaster if your device was stolen and this information fell into the wrong hands. A "wallet" gets around this by encrypting the data before storing it. Each time you open the application you type in a password, which is used to encrypt and decrypt the data.
The thing to remember about strong encryption is that the key is all important. Nobody can access your credit card details without the key, not even the person who wrote the wallet program (unless they have written a "backdoor" into the program).
As a final example, suppose you have written computer game, and you want to store each player’s current level in a data file. You don’t want players to be able to cheat by editing the data file, so you decide to encrypt it. The program has a fixed key built in, which it uses to encrypt and decrypt the data.
This final example is not secure. The key is built in to the program, and a smart hacker with the right tools could quite easily pick your program apart and find the key. However in this particular case it is probably not too much of a problem, because the data isn’t very important.
There is a second aspect of encryption which can be useful. When B receives an encrypted message, assuming it decrypts to produce a sensible message, he can be pretty sure it was sent by A because nobody else would be capable of generating an encrypted message.
You need to be very careful with this assumption, because not all algorithms are totally secure in this way. There may be ways that an attacker can make changes to a message without knowledge of the key. For example, he might have recorded encrypted data from a previous message which can then be injected into a new encrypted message giving a result which might appear sensible. Using [[data formats:cryptography:Cryptographic modes|CBC mode]] helps guard against this attack. In general it is better to use a [[data formats:cryptography:Cryptographic hash|hash]], a [[data formats:cryptography:Message Authentication Code]] or some kind of digital signature to validate the data.
Due to the highly complex relationship between the plaintext, the key and the ciphertext, it is possible to use an encryption algorithm as the basis of a [[data formats:cryptography:Cryptographic hash]] or [[data formats:cryptography:Message Authentication Code]].
For similar reasons to the hash case, encryption algorithms can be used as the basis of pseudo-random number generators. The general idea is that, whatever you feed into the encryption algorithm, the output will tend to have strongly random characteristics.
Copyright (c) Axlesoft Ltd 2020