An encryption algorithm is a mathematical function that transforms plaintext into ciphertext. Choosing the right algorithm is important because vulnerabilities may be discovered over time, or advances in computing processing power may mean that a brute-force attack (ie attempting every possible key) is no longer a time-consuming task.
The ‘Data Encryption Standard’ or DES was developed in the 1970s and standardised as a ‘Federal Information Processing Standard’ in 1977 (FIPS 46). It had a total of 72 quadrillion possible keys.
By the late 1990s, computing power had advanced to the point that it was possible to ‘crack’ a DES key in less than 24 hours by conducting a brute-force search of all possible keys.
The Advanced Encryption Standard (AES) was subsequently published as a replacement for DES as FIPS 197. AES with a 256-bit key size has a potential 115 quattuorvigintillion possible keys, or 115 with 78 digits following it. There is presently no known practical attack that could brute-force an AES 256 key.
You should therefore regularly assess whether your encryption method remains appropriate.
Rather than develop a custom algorithm it is recommended that you use a trusted and verified algorithm. Accredited products (see ‘Choosing the right software’ below) can provide an assurance of suitability and also permit you to demonstrate a level of compliance with legal obligations. However, it is important to keep the products being used under regular review, due to the nature of technical development over time.
Algorithms use keys to encrypt and decrypt data. Encrypting the same data with a different key will produce a different result. Just as it is important to choose the right algorithm, it is also important to ensure that the key size is sufficiently large to defend against an attack over the lifetime of the data. As computing processing power increases or new mathematical attack methods are discovered, a key must remain sufficiently large to ensure that an attack remains a practical impossibility.
The RSA algorithm is one of the first public-key systems and is used for secure data transmission. It has a potential maximum key size of 4096-bits.
For a number of years, key sizes of 1024-bits were commonplace. However, in 2007, the National Institute of Standards and Technology recommended increasing minimum key size due to advances in computing power. The minimum recommended was 2048-bits up to the year 2030, and 3072-bits after 2030.
This required some certificate providers to increase the key size of their certificates to take account of the recommendation. In other cases, operating system providers took the decision to issue security updates informing administrators of the change.
You should therefore regularly assess whether your encryption keys remain sufficiently large to prevent a brute force or other method of attack. You should also assess the risks and likelihood of an attack given the amount and type of personal data you hold.
The way that encryption software is put together is also crucially important. Software can use a state-of-the-art algorithm and a suitably long key to output encrypted data, but if its development did not follow good practice, or the product itself is poorly tested or subject to insufficient review, there may be vulnerabilities or other opportunities for attackers to intercept data or break the encryption without the users’ knowledge. It is also possible that the encryption software includes an intentional weakness or backdoor to enable those with knowledge of that weakness to bypass the protection and access the data.
In cases where it is of critical important to have an assurance that these vulnerabilities do not exist, it is therefore important to gain an external assessment of encryption software. Such an assessment may also assist you in defining an appropriate algorithm and key size.
It is recommended that you ensure that any solution that you, or a data processor acting on your behalf, implement meets current standards such as FIPS 140-2 (cryptographic modules, software and hardware) and FIPS 197 (PDF). Encryption products certified via the National Cyber Security Centre’s CPA Foundation grade or CAPS scheme would also meet the current standard. (You should also note that the reference to certification here is not to certification under Articles 42 and 43 of the GDPR.)
You can also find additional information on the current status of encryption algorithms in the following publications:
- guidance from the European Union Agency for Network and Information Security (ENISA) on Recommended cryptographic measures as well as its Algorithms, key sizes and parameters report (2014); and
- the United States National Institute of Standards and Technology Special Publication 800-131A Revision 1 (Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths).
In some instances such specific assurances may not be available. For example, many open source software products do not have sufficient capital to fund an appropriate external assessment. However, government security agencies and private IT security organisations can offer advice regarding which specific protocols or algorithms which should be considered appropriate, although you should be aware of the limited assurances when no assurance or guidance is available. An example of such advice from the NCSC on the use of TLS includes:
‘The lack of formal assurance in TLS implementations means there may be implementation weaknesses. Using recent, supported and fully patched versions of TLS implementations from reputable sources will help to manage this risk.’
This statement highlights the importance of keeping software up to date as vulnerabilities in the code may be discovered over time, eg Heartbleed and Shellshock.
It is important to ensure that symmetric keys and private keys remain secret as these provide the ability to decrypt the data.
In many cases keys are stored in a hierarchy for ease of management. The top level key is used to encrypt the keys below it and must therefore be managed securely.
All keys should have a finite lifespan and you need processes in place to generate a new key and re-encrypt the data. The old key should then be archived and securely deleted when no longer required.
In symmetric encryption, the key is sometimes derived from a shorter, more memorable password. It is therefore imperative that any password used to derive or secure the keys also remains secret. A poor choice or a compromise of the password can significantly lower, or even eliminate, the level of protection offered by an encryption product.
In the event that the key is compromised, or even if this possibility cannot be excluded, it may be necessary to revoke the existing key and generate a new key or key pair to protect data in the future.
It is also the case that loss of the decryption key will likely mean that no-one will be able to gain access to the data. Depending on the circumstances, loss of the decryption key could constitute ‘accidental loss, destruction or damage’ to personal data and would therefore be a contravention of the GDPR’s security principle; additionally, if you cannot restore the data, this may also constitute a personal data breach due to a lack of availability, depending on the risks this poses.
A laptop is protected using a secure full disk encryption product. This means that when the laptop is switched off the personal data is stored in an encrypted form.
If the laptop is stolen and the thief powers on the laptop he is challenged for the password. Without knowledge of the password the attacker is unable to access the data.
However, if the laptop user’s username and password were written on a piece of paper stored alongside the laptop the thief has all the necessary information in order to decrypt the data and gain full access to it, thereby rendering the encryption ineffectual.
Encryption publications from the European Union Agency for Network and Information Security (ENISA):
- Report on recommended cryptographic measures (2013) (PDF)
- Study on cryptographic protocols (2014) (PDF)
- Algorithms, key sizes and parameters report (2014) ) (PDF)
NIST Federal Information Processing Standards and Special Publications:
- FIPS 197 – the Advanced Encryption Standard (2001) (PDF)
- FIPS 140-2 – Security requirements for cryptographic modules (2002) (PDF)
- SP800-131A Revision 1 – Transitions: Recommendations for transitioning the use of cryptographic algorithms and key lengths (2015) (PDF)
NCSC certified products schemes and further guidance: