So far in this short guide to encryption, we have looked at some of the terms associated with an encryption system, and some of the desirable qualities such a system should have.
We have explained the terms encryption & decryption, plain-text, cipher-text, algorithms, keys, and entropy.
Along the way, we have seen other features associated with encryption such as transposition and substitution. In this post we take a more in-depth look at keys.
Cryptographic keys
As previously seen, a key in cryptography is a piece of information (typically a string of numbers or letters) which, when processed through a cryptographic algorithm, can encode or decode information.
The strength of the encryption relies on the security of the key being maintained. Remember Shannon’s Maxim? “The enemy knows the system”.
The security strength of a key is dependent on a number of factors:- the size of the key, the generation of the key, and the process of key exchange.
Size of key
In the last post, I explained how a high entropy value is a desired factor in a key – the greater the number of possible values a key can have, the stronger it is in resisting being discovered.
A key of 1 alpha-numeric character could have 62 possible values (26 lower-case letter , 26 upper-case letters and 10 numbers). Which is very weak in terms of entropy.
Extending the key length by a 2nd character gives 622 possible keys (3,844) a 3rd character gives 623 keys (238,328), and so on. To generate a key with sufficient strength in modern computing arenas would require a very lengthy string of alpha-numeric characters.
In the world of modern cryptography, a key is represented as a numeric value, stored as a sequence of bits. Every alpha-numeric character can be expressed as a sequence of 8-bits.
The letter “A” is mapped by the ASCII character map as decimal 65. In binary, the representation is 01000001 (8-bits). The letter “B” is decimal 66, which is 01000010. The maximum number of values 8 bits can have is 256 (28)
To put this into context for key length, NIST – the American National Institute for Science and Technology recommend that when using RSA (a common encryption standard used by Internet systems) a key length of 2,048 bits is required to keep data safe until approx. 2030. At that point, computing power will be sufficient to process all possible key values to deem 2,048 bits weak.
In 2007 a team of researchers using 400 computers factored all possible combinations of a key with a length of 1,024 bits in 11 months. As such, NIST recommended moving to 2,048 bits for all RSA systems in 2015 because the same feat could be achieved in a matter of hours at that time.
Key generation
In many cases, encryption keys on modern computer systems are randomly generated using a random number generator (RNG) or pseudorandom number generator (PRNG).
A PRNG is a computer algorithm that produces data that appears to be random under analysis. PRNGs that use system entropy to seed data generally produce better results, since this makes the initial conditions of the PRNG much more difficult for an attacker to guess.
System entropy can be gathered in different ways – a system could use power fluctuations to generate random data for example, or the sporadic movement of the read/write head on a hard-disc drive to generate a signal.
Another way to generate randomness is to utilise information from outside the system. Cloudflare uses a wall of lava lamps in its head office in San Francisco to generate randomness. This wall of floating bubbles is constantly recorded and the video signal is converted to a bit stream which is used as the seed for the number generator which provides the key material for their encryption systems.
Key exchange
Producing a secure key is one thing, but how do you distribute the keys you create to others in a safe and secure manner?
In the world of cryptography, there are two distinct types of encryption systems we can use – those which use symmetric keys, and those which use asymmetric keys.
Symmetric key systems encrypt and decrypt data with the same key, whereas Asymmetric key systems encrypt and decrypt data with two linked keys, one for encryption, and one for decryption – these systems are often called public/private key systems.
Symmetric key systems can process data fairly quickly due to the fact that because only one key is needed.
If used in a highly secure environment, symmetric keys are very safe and efficient. However, if the key becomes compromised, then all data encrypted with that key is deemed to have been compromised, and the key can never be used again.
Key management is a crucial part of any encryption system, but especially so with symmetric keys. If the two communicating parties have an assured, safe mechanism for key exchange then the system remains safe to use, but if the two parties cannot guarantee safe key exchange, then the system should not be trusted.
When using symmetric keys, a different key is required for each participant, otherwise people could decrypt and read other people’s data.
So if there are only two people communicating, 1 key is required:
A<->B
If there are three people communicating, then 3 keys are required:
A<->B
A<->C
B<->C
If there are 4 people communicating, then 6 keys are required
A<->B
A<->C
A<->D
B<->C
B<->D
C<->D
Five people requires 10 keys
A<->B
A<->C
A<->D
A<->E
B<->C
B<->D
B<->E
C<->D
C<->E
D<->E
As you can see, this could quickly get very messy and in terms of key management – very complex.
Asymmetric key systems use a pair of keys which are mathematically related but due to how they are generated, very hard to determine the value of one key if you have access to the other.
These keys are commonly called public and private keys from the fact that you can freely distribute the public key in any manner of your choosing, so long as you keep the private key safe.
The use of public/private keys removes the issues surrounding key distribution – you can send people your public key in the post, you can print it on billboards, you can advertise it on a website – you can share the key however you see fit. The most common way to share a public key is via a digital certificate.
When visiting a website which uses encryption, your browser receives the servers public key as a value within the servers digital certificate. It uses that key to encrypt data which can only be decrypted by the servers private key
This approach also removes the issue of managing hundreds of keys – with Asymmetric key systems, only one pair of keys is required no matter how many users are involved in conversations. Data encrypted with the public key cannot be decrypted by others who have the same public key, the data can only be decrypted by the private key.
The problem with public/private key systems is that due to the complex maths used to generate two related, yet highly secure, random keys, such systems have a high cryptographic processing overhead which could slow down data transfer.
To resolve this issue, the approach taken in most cases is to use Asymmetric key systems as a mechanism for creating a secure environment for the exchange of symmetric key material.
Take SSL/TLS as the example. When a browser connect s to a website using TLS, the browser downloads the web servers public key – therefore it now has a way of sending dfata to the server which only the server can decrypt.
The browser generates a unique seed value for creating a symmetric key and encrypts this data with the servers public key material.
This data can now be safely sent over the Internet to the web server along with a chosen encryption algorithm for generating the key.
Both browser, and web server use the same seed data, and algorithm to produce the exact same symmetric key – that key is now used for data transfer during the communication session and is destroyed once the session has completed – hence why this symmetric key is often called the session key.
In the next post, we shall take a more detailed look at cryptographic hashes.
