Understanding Symmetric vs Asymmetric Encryption

When it comes to talking about encryption, it’s important to ensure we’re speaking about the same thing – and to clarify and simplify some of the different implementations we see. Sometimes these are implemented for security and best practice, while other times they are implemented to tick a box. It's important to know the difference between encryption mechanisms, know when to use what and be able to identify and judge the security of particular implementations. This is the first of 2 or more posts.

A Guide to Symmetric and Asymmetric Encryption Mechanisms

When we talk about encryption we talk about symmetric encryption or asymmetric encryption.

Symmetric encryption

This means the same key used to encrypt data is also used to decrypt data. For obvious reasons, this key is often referred to as a “secret key”.

Examples of symmetric keys: DES, TDES, AES

The DES key is a 56-bit key and is padded out to 64-bit. The 8 bits are used for parity and to protect against errors in key usage. TDES is a bundle of three DES keys (format per ANSI TR-31). This bundle can be double length or triple length and is written in terms of the bit length or the key strength. This is why a TDES triple length key can be written as 192-bit (with parity) or 168-bit (without parity). Note that double length TDES is generally deprecated except in a DUKPT implementation. DUKPT means Derived Unique Key Per Transaction - there's a previous blog post on that here.

Given the TDES algorithm is made of a bundle of keys the way it is used reflects this. For example, a TDES triple length key can perform encryption operations using the EDE3 method – EDE is encrypt, decrypt, encrypt.

This is how it works: clear text encrypted with key1, decrypted with key2, encrypted with key3. The resultant cipher text is the cryptogram of the clear text encrypted with the TDES triple length key using a EDE function. You'll see EDE sometimes when looking at cipher mechanisms in HTTPS implementations. We'll look at how HTTPS works later.

DES and 2DES are both deprecated as they are of insufficient strength.

The AES algorithm is the Advanced Encryption Standard and key lengths are usually 128-bit, ,192-bit, 256-bit, 512-bit

The integrity of the secrecy of the key in symmetric encryption is paramount. Consider Kerckhoff's Principle:

A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.

In relation to Kerckhoff's Principle, it's important to note that the actual mathematical workings of encryption are public knowledge and far too complicated for this article! Interesting concepts like feistel rounds and S-boxes and lots of exclusive OR operations will be touched on next.

eXclusive OR

You'll probably know that a recognised way of creating and transporting symmetric keys is through key components. Key components are binary strings (series of bits) which can be concatenated (joined) together to create the encryption key. The concatenation occurs using an exclusive OR operation - this is generally written as XOR and works as follows... as an aside I'll touch on modular maths here to pre-empt the XOR and it'll be useful for asymmetric encryption later.

Modular maths

The easiest way to think of this initially is to consider the 12-hour clock. If we add 3 hours to 11 o'clock we get 2 o'clock. This means we're working with modulo 12. So 4*4= 4 (16), 3*4=0 (12), 7*2=2 (14).. this goes on through multiples of 12 also so 7*4=4 (28), 10*4=4(40)

In an XOR operation we work with modulo 2 and we work at the bit level so let's say we have a key component 11010110 and 01011000 and we want to use these to create a key. I'm adding here as opposed to multiplying above but there's a reason! So 1+1=0, 0+0=0,1+0=1 so we'd have

KeyComponent1 XOR KeyComponent2 = EncryptionKey

11010110  XOR

01011000

=

10001110

You can see above that key components aren't key shares or parts of encryption keys but are quite separate. A key custodian who has knowledge of their key component does not have knowledge of the encryption key or any part thereof. However, collusion between custodians of key components must be avoided. To enforce this, they should have separate line managers, separation of duties, access control to separate key component storage areas etc...

Creation of key components and encryption keys usually use a Pseudo Random Number Generator (PRNG) or sometimes you can enter a password which will derive a key for a particular use. This latter is called Password Based Key Derivation Function (PBKDF)

Moving swiftly on....

Asymmetric encryption

This means different keys are used for encryption and decryption. The convention is that the public key is used for encryption and the private key is used for decryption. The private key is also used for signing public keys, applications, digital signatures etc. We'll consider HTTPS key exchange to illustrate asymmetric keys and symmetric key use in practice.

The minimum strength for certificates used for HTTPS communications is RSA 2048-bit keys. The effective bit strength of a RSA 2048-bit key, according to NIST is 112-bits which makes it equivalent to a TDES triple length key.  Here’s a reference table from the PCI P2PE standard consistent with NIST SP 800-57:

The creation of key pairs uses modulo maths and uses a large prime number as the modulo. The reason for is using a prime as the modulo means the results of basic multiplications don't have repeating results. This uniqueness allows the exchange of data to have predictable and specific results once the modulo is known.

All modern browsers include a list of certificate authorities they trust so, when you open a page in a browser and the web page submits a certificate, the browser looks up its certificate register and validates the certificate was issued by, and is signed by, a recognised certificate authority. To see the list in Chrome, select settings, advanced settings, manage certificates. Here you can see trusted publishers and trusted roots which browsers will accept and untrusted and fraudulent certificates which browsers will reject.

Key exchange

1. I open a web page and the web states it is www.sitename.com and it has a public certificate signed by Acme CA. The public certificate (x.509 format) contains information about the website - DNS name(s), protocols supported, cipher suites, public key
2. My browser checks its trusted certificates and verifies Acme CA is trusted. A little green padlock appears in the address bar.
3. My browser creates a symmetric key according to the cipher suites agreed e.g. TLS_RSA_WITH_3DES_EDE_CBC_SHA - this is using Transport Layer Security using an RSA asymmetric key with a Triple DES key operating an Encrypt Decrypt Encrypt method using Cipher Block Chaining and a SHA hash algorithm (the data exchanged is signed and hashed – the hashes are matched to verify the signatures).
4. The public key provided by the server is used to encrypt the symmetric key. This cryptogram, (the cipher text of the symmetric key encrypted by the asymmetric key) is sent back from my client to the web server
5. The web server uses its private key to decrypt the symmetric key
6. The symmetric key is used to encrypt further communications between my client and the server

Asymmetric keys are long which means that they have a processing overhead for encryption/decryption operations. Using the asymmetric keys to exchange the symmetric keys means the encryption overhead is minimal, secrecy is ensured, a symmetric key is shared and further encryption operations are quick.

Once the session terminates, the encryption key used for the sessions is destroyed.

The next blog post will consider some implementations for encryption of data at rest.