This article answers 14 typical questions about cryptography you may get during a job interview for a security position or any IT-related assignment for that matter.

When working in IT, it is easy to skip over and assume the correctness of certain often used technologies. Especially in the field of cryptography it is a good idea to not try and reinvent the wheel, but use well maintained libraries and proven technology. However, to really advance in any IT field, it is important to understand the details of the technologies you work with. That is why during a job interview, the basic topics are often covered to probe the applicant's knowledge level of the technical part of the job he or she is applying for.

Daniel Miessler wrote an excellent blog post stating 60 Information Security Interview questions. I selected the questions from his Encryption section and tried to answer them here.

Contents

SSL / TLS:

• What’s the difference between symmetric and public-key cryptography?
• Does TLS use symmetric or asymmetric encryption?
• In public-key cryptography you have a public and a private key, and you often perform both encryption and signing functions. Which key is used for which function?
• Describe the process of a TLS session being set up.
• If someone steals the server’s private key can they decrypt all previous content sent to that server?
• What are some common ways that TLS is attacked, and/or what are some ways it’s been attacked in the past?

Principles and algorithms:

• Cryptographically speaking, what is the main method of building a shared secret over a public medium?
• What’s the difference between Diffie-Hellman and RSA?
• What kind of attack is a standard Diffie-Hellman exchange vulnerable to?
• What is Forward Secrecy?
• What’s the difference between encoding, encryption, and hashing?
• What is an IV used for in encryption?
• What are block and stream ciphers? What are the differences, and when would you use one vs. the other?
• What’s the main difference in security between the two common block cipher modes ECB and CBC?

If you're new to the world of cryptography, it is a good idea to understand the basic terminology before reading the answers to these questions. That's why I included the tiniest glossary in the history of the Internet as a starter.

Glossary

Plaintext / Cleartext
Information a sender wishes to transmit to a receiver. Plaintext is in a format that is directly usable by the sender and receiver, i.e. unencrypted

Cipher
In cryptography, a cipher (or cypher) is an algorithm for performing encryption or decryption. In other words, it is a series of well-defined steps that can be followed as a procedure to transform plaintext into ciphertext (encryption) and vice versa (decryption).

Ciphertext
Ciphertext is the result of encryption performed on plaintext using an algorithm (cipher). It is also known as encrypted or encoded information because it contains a form of the original plaintext that is unreadable by a human or computer without the proper cipher to decrypt it.

What’s the difference between symmetric and public-key cryptography?

Symmetric cryptography

Symmetric cryptography involves only one secret key to encrypt and decrypt information. This secret key is used on the plaintext message to change the content in a certain way (encrypt). Both the sender and recipient know the secret key so they can encrypt and decrypt all the messages.

This process is depicted in the figure below, where Alice sends an encrypted message to Bob using a shared key.

The main disadvantage of the symmetric key encryption is that the shared secret key needs to be exchanged between all parties involved before they can decrypt the message. Intercepted messages can be easily decrypted if the interceptor knows the secret key.

Some examples of symmetric encryption algorithms are Blowfish, Rijndael (AES), DES and RCx.

Public key cryptography

Public key, or asymmetric cryptography, is relatively new compared to symmetric cryptography. Public key encryption uses a pair of a public key and a private key to perform different tasks. The public and private key are mathematically related, but not identical. Public keys are widely distributed, while private keys are kept secret, which is useful in two scenario's:

Encryption
Using a person’s public key, it is possible to encrypt a message so that only the person with the private key can decrypt and read it.

In the picture below, Alice sends a message to Bob. She uses Bob's public key to encrypt the message. Bob is the only one able to decrypt the message, since he holds the corresponding private key.

Signing
Using a private key, a digital signature can be created so that anyone with the corresponding public key can verify that the message was created by the owner of the private key and was not modified since.

In the figure below, Alice wants to send a message to Bob and creates a digital signature of her message by signing it using her private key. She then sends the message together with the signature to Bob, who can verify the authenticity of the message using Alice's public key. Note that the message in this example is not encrypted.

Some examples of public key encryption algorithms and applications are Diffie-Hellman key exchange, RSA, GPG, DSA, elliptic curve techniques, ElGamal and SSH.

Does TLS use symmetric or asymmetric encryption?

Both. TLS (and SSL) use a combination of symmetric and asymmetric encryption to ensure message privacy. Simply stated, the initial handshake is performed using asymmetric encryption to negotiate a shared secret key and algorithm. This key is used for the bulk (symmetric) data encryption for one session only. From then on all messages transmitted between the TLS client and server are encrypted using that shared key and algorithm, ensuring that the message remains private even if it is intercepted. Because TLS uses an asymmetric encryption when transporting the shared secret key, there is no key distribution problem.

Why isn't the asymmetric algorithm used for the encryption of the bulk data? Simple answer: performance. Symmetric algorithms are faster for processing bulk data, while negotiating of the shared key may be a challenge for symmetric algorithms. That's why a combination of symmetric and asymmetric encryption is used in TLS.

In public-key cryptography you have a public and a private key, and you often perform both encryption and signing functions. Which key is used for which function?

Encryption is done with the other person's public key. Signing is done with your own private key.

Describe the process of a TLS session being set up

The setup process of a TLS session is depicted in the image below.

Setting up a TLS session goes as follows (source):

1. The client sends a "client hello" message that also lists the cryptographic information such as the TLS version and the cipher suites (algorithms) and data compression methods supported by the client. A random byte string is included for use in subsequent computations.
2. The server responds with a "server hello" message that contains the cipher suite chosen by the server from the list provided by the client, the session ID and another random byte string. The server also sends its digital certificate.
   If the server requires a certificate for client authentication, it also sends a certificate request to the client that includes a list of the supported types of certificates and acceptable Certificate Authorities.
3. The client verifies the server's digital certificate.
4. The client sends the random byte string that enables both the client and the server to compute the shared secret key to be used for encrypting subsequent message data. The random byte string itself is encrypted with the server's public key (see public key encryption).
5. (optional) If the server sent a client certificate request, the client sends a random byte string encrypted with the client's private key, together with the client's digital certificate, or a 'no digital certificate' alert (see signing). This alert is only a warning, but with some implementations the handshake fails if client authentication is mandatory.
6. (optional) The server verifies the client's certificate.
7. The client sends the server a "finished" message, that is encrypted with the shared secret key, indicating that the client part of the handshake is complete.
8. The server sends the client a "finished" message, that is encrypted with the shared secret key, indicating that the server part of the handshake is complete.
9. For the duration of the SSL or TLS session, the server and client can now exchange messages that are symmetrically encrypted with the shared secret key.

If someone steals the server’s private key can they decrypt all previous content sent to that server?

The key (pun intended) to this answer is Forward Secrecy. This prevents an attacker from decrypting captured data that was sent to a server in the past, even if the server's private key was stolen. See the question about Forward Secrecy further on in this article.

What are some common ways that TLS is attacked, and/or what are some ways it’s been attacked in the past?

Many common TLS misconfigurations originate in a poor choice of cipher suites. Old or outdated cipher suites, especially those that suffer from different kinds of attacks, may allow an attacker to successfully intercept or tamper with secret data in transit.

When thinking of past attacks on TLS, three of these spring to mind because of the public exposure they got: POODLE, BEAST and Heartbleed. You know things get serious when a vulnerability has its own logo...

POODLE (CVE-2014-3566)

The Padding Oracle On Downgraded Legacy Encryption attack was discovered by Google researchers Bodo Möller, Thai Duong and Krzysztof Kotowicz, who released a paper on it in September 2014.

In short, this vulnerability in the SSL 3.0 protocol allows the plaintext of secure connections to be calculated by a network attacker. Nearly all browsers support SSL 3.0 and, in order to work around bugs in HTTPS servers, browsers will retry failed connections with older protocol versions (downgrade), including SSL 3.0. Because a network attacker can cause connection failures, they can trigger the use of SSL 3.0 and then exploit this issue.

The exact workings of the POODLE attack are out of scope for this blog post, but Troy Hunt did a great explanation in this article.

BEAST (CVE-2011-3389)

The Browser Exploit Against SSL/TLS attack was published in September 2011 and affects SSL 3.0 and TLS 1.0. An attacker can “decrypt” data exchanged between two parties by taking advantage of a vulnerability in the implementation of the Cipher Block Chaining (CBC) mode in TLS 1.0 which allows them to extract the unencrypted plaintext from an encrypted session.

As the name implies, this attack is performed client-side (browser) and it is done via a man-in-the-middle (MiTM) approach. Using MiTM, an attacker can inject packets into the TLS stream. This allows an attacker to guess the Initialization Vector used in XORing with the message they injected, and then simply compare the results to the ones of the block they want to “decrypt”.

It’s worth noting that for the BEAST attack to succeed, an attacker must have reasonable control of the victim’s browser. This makes it more probable for an attacker to choose an easier attack vector.

Read the detailed description of the BEAST attack in Thai Duong's original article.

Heartbleed (CVE-2014-0160)

Heartbleed is a critical vulnerability in the OpenSSL cryptographic software library. It allows anyone to read the memory of the systems protected by the vulnerable versions of the OpenSSL software.
Heartbleed can compromise the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

Heartbleed is best explained by the excellent xkcd comic:

Cryptographically speaking, what is the main method of building a shared secret over a public medium?

Diffie-Hellman (DH). Using the metaphor of mixing paint (credits to this excellent Wikipedia article for the idea), the image below shows how DH works when Alice and Bob want to build a shared secret:

The process starts with having Alice and Bob agreeing on an arbitrary starting color (yellow in this case). This color does not need to be kept secret, but should be different every time. Both Alice and Bob select a secret color that is only known to themselves. In the example above Alice selects red and Bob selects blue.

Alice and Bob both mix the mutually selected color (yellow) with their own secret colors, resulting in two new colors (Alice: orange, Bob: green). Alice and Bob then publicly exchange the two mixed colors. Finally they both mix the color they received with their own secret color resulting in the final color mixture that will be identical to their partner's final color mixture.

This final mixture is the shared secret Alice and Bob will both use when exchanging data (or painting their houses if they're both into purple).

What’s the difference between Diffie-Hellman and RSA?

Diffie-Hellman is a key-exchange protocol (see building a shared secret), and RSA (short for Rivest–Shamir–Adleman, its inventors) is an encryption/signing protocol. Besides that, the main difference is that for RSA it is required for both parties to have key material beforehand, while for Diffie-Hellman, this is not required.

The RSA protocol is out of scope for this article and certainly worth a blog post of its own. However, Jeronimo (Jerry) Garcia did a great job explaining RSA in this Hackernoon article.

What kind of attack is a standard Diffie-Hellman exchange vulnerable to?

See building a shared secret on how Diffie-Hellman works. Since with Diffie-Hellman neither sides are authenticated, this protocol is vulnerable to man-in-the-middle attacks. Read my article 'executing a man-in-the-middle attack' for further information on this topic.

What is Forward Secrecy?

Forward Secrecy is a system that uses very short lived (ephemeral) session keys to do the actual encryption of TLS data so that even if the server’s private key were to be compromised, an attacker could not use it to decrypt captured data that had been sent to that server in the past.

Consider an example where Alice wants to send a message to Bob:

Initially, Alice and Bob are using a previously determined shared session key k to encrypt their messages. For every subsequent message a new session key will be used. This key is calculated by taking the hash of the previous key.

So, if message 1's key is \(k\), then the key for message 2 will be the hash of message 1's key, or \(hash (k))\). Message 3 will have \(hash (hash (k)))\) as its key and so forth.

In short, the key of message \(n\) is the hash of the key of message \({n-1}\): \(key_{message_n} = hash(key_{message_{n-1}})\)

The hash function needs to meet two security requirements:

• one-way - It should not be possible to calculate the key back from the hash. If it is possible to calculate a key \(k\) from any \(hash(k)\), the entire system is insecure.
• collision resistant - Each iteration of the hash (i.e. for every new message), the hash function should yield a new unique key that has never been produced before. If the hash function at a certain moment would yield a key that was already used for a message in the same sequence in the past, it would be possible to calculate all the subsequent keys up till that moment.

What’s the difference between encoding, encryption, and hashing?

Encoding is designed to protect the integrity of data as it crosses networks and systems. It isn't primarily a security function, but rather keeps its original message upon arriving. It is easily reversible because the system for encoding is almost necessarily, and by definition widely used. In the OSI model, the presentation layer takes care of the encoding of messages.

Encryption is designed purely for confidentiality and is reversible only if you have the appropriate key/keys.

With hashing the operation is one-way (non-reversible), and the output is of a fixed length that is usually much smaller than the input.

What is an IV used for in encryption?

An Initialization Vector (IV) is used to initiate encryption by providing an extra (third) input in addition to the plaintext and the key. This is done to ensure that two messages that are encrypted with the same key do not result in the same ciphertext. IVs are typically required to be random or pseudorandom.

What are block and stream ciphers? What are the differences, and when would you use one vs. the other?

A block cipher algorithm operates on fixed-length groups of bits, called a block, with a fixed transformation that is specified by a symmetric key. These algorithms are important elementary components in the design of many crypto protocols. Block ciphers are best used for encrypting bulk data where you know how large the message will be (e.g. file transfer). The next question will elaborate more on two of these block ciphers.

Stream ciphers work on single units of plaintext, such as a bit or a byte. They're best used when you're not sure how long the message will be, like streaming video for example.

Consider the following scenario: Alice wants to live-stream video footage directly to Bob and needs to do this via an encrypted channel. They decide to use a stream cipher. Alice and Bob negotiate a shared key that is used as input for a keystream generator.
Each byte of the video footage is encrypted one at a time with the next byte from the keystream resulting in a byte of the encrypted video stream.

Some examples of stream ciphers are ChaCha, RC4, FISH, SOBER-128 and Rabbit.

What’s the main difference in security between the two common block cipher modes ECB and CBC?

ECB (Electronic Code Book) is the most basic form of block cipher encryption. It doesn't use an IV, so any same plaintext that goes into the cipher, produces the same ciphertext:

The main idea of ECB encryption is to split the plaintext into blocks of N bits, and then to encrypt each block of plaintext using the only key. The resulting blocks of ciphertext are concatenated and sent.

CBC (Cipher Block Chaining) is an advanced form of block cipher encryption. With CBC, each ciphertext block is dependent on all plaintext blocks processed up to that point.

CBC uses an IV block for the first block and then propagates the previous block onto the subsequent ones. This adds an extra level of complexity to the encrypted data.

The practical difference between ECB and CBC is best illustrated with this graphic:

Closing thoughts

Of course there are many more questions to be asked when the cryptography topic arises during a job interview. The subset of these questions covered in this blog post involve some of the basics of the technology we use every day. Knowing the answers to these questions may help you land your first job in the information security world or extend your knowledge on this subject.

Cover photo by Tim Evans