Written by Andrew McKenna, PCI, PA, P2PEQSA at Foregenix

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.
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 56bit key and is padded out to 64bit. 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 TR31). 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 192bit (with parity) or 168bit (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 128bit, ,192bit, 256bit, 512bit
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 Sboxes 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 preempt 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 12hour 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 2048bit keys. The effective bit strength of a RSA 2048bit key, according to NIST is 112bits which makes it equivalent to a TDES triple length key. Here’s a reference table from the PCI P2PE standard consistent with NIST SP 80057:
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
 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
 My browser checks its trusted certificates and verifies Acme CA is trusted. A little green padlock appears in the address bar.
 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).
 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
 The web server uses its private key to decrypt the symmetric key
 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.