Cryptography Interview Questions and Answers

In cryptography a key is a piece of information used in combination with an algorithm (a cipher) to transform

plaintext into ciphertext (
encryption) and vice versa (
decryption).
A cipher can be

reciprocal if it is used for both encryption and decryption, or non-reciprocal if a transformation to the key is required when using it in reverse.

Data encryption translates data into another form, or code, so that only people with access to a secret key

(formally called a
decryption key) or password can read it. Encrypted data is commonly referred to as
ciphertext,
while unencrypted data is called
plaintext.

To use asymmetric encryption, there must be a way of discovering public keys. One typical technique is using digital certificates in a client-server model of communication. A certificate is a package of information that identifies a user and a server. It contains information such as an organization’s name, the organization that issued the certificate, the users’ email address and country, and users public key. When a server and a client require a secure encrypted communication, they send a query over the network to the other party, which sends back a copy of the certificate. The other party’s public key can be extracted from the certificate. A certificate can also be used to uniquely identify the holder.

Asymmetric encryption is also known as public key cryptography, which is a relatively new method, compared to symmetric encryption. Asymmetric encryption uses two keys to encrypt a plain text. Firstly, a public key must be made public in order to encrypt the data. Secondly, a private key used to decrypt the data. The public key and the private key are not the same thing but they are related. You create your message then encrypt it with the recipient’s public key. After that, if the recipient wants to decrypt your message he/she would have to do it with his/her private key. Asymmetric encryption is mostly used in day-to-day communication channels, especially over the Internet. Popular asymmetric key encryption algorithm includes EIGamal, RSA, DSA, Elliptic curve techniques, PKCS.

The important part is what they do and how they do it: MD5 and SHA are hash functions (SHA is actually a family of hash functions) - they take a piece of data, compact it and create a suitably unique output that is very hard to emulate with a different piece of data. They don't encrypt anything - you can't take MD5 or SHA output and "unhash" it to get back to your starting point. The difference between the two lies in what algorithm they use to create the hash. Also note that MD5 is now broken as a way was discovered to easily generate collisions and should not be used nor trusted anymore. RSA is an assymetric encryption algorithm. You have two keys (private and public) and you can perform a function with one key (encrypt or decrypt) and reverse with the other key. Which key you use depends on whether you are trying to do a digital signature or an encryption.

Block Cipher and Stream Cipher are the methods used for converting the plain text into cipher text directly and belong to the family of symmetric key ciphers. The major difference between a block cipher and a stream cipher is that the block cipher encrypts and decrypts a block of the text at a time. On the other hand, stream cipher encrypts and decrypts the text by taking the one byte of the text at a time. Stream ciphers are typically faster than block, but that has it's own price. Block ciphers typically require more memory, since they work on larger chunks of data and often have "carry over" from previous blocks, whereas since stream ciphers work on only a few bits at a time they have relatively low memory requirements (and therefore cheaper to implement in limited scenarios such as embedded devices, firmware, and esp. hardware). Stream ciphers are more difficult to implement correctly, and prone to weaknesses based on usage - since the principles are similar to one-time pad, the keystream has very strict requirements. On the other hand, that's usually the tricky part, and can be offloaded to e.g. an external box.

Because block ciphers encrypt a whole block at a time (and furthermore have "feedback" modes which are most recommended), they are more susceptible to noise in transmission, that is if you mess up one part of the data, all the rest is probably unrecoverable. Whereas with stream ciphers bytes are individually encrypted with no connection to other chunks of data (in most ciphers/modes), and often have support for interruptions on the line. Also, stream ciphers do not provide integrity protection or authentication, whereas some block ciphers (depending on mode) can provide integrity protection, in addition to confidentiality. Because of all the above, stream ciphers are usually best for cases where the amount of data is either unknown, or continuous - such as network streams. Block ciphers, on the other hand, or more useful when the amount of data is pre-known - such as a file, data fields, or request/response protocols, such as HTTP where the length of the total message is known already at the beginning.

To use asymmetric encryption, there must be a way of discovering public keys. One typical technique is using digital certificates in a client-server model of communication. A certificate is a package of information that identifies a user and a server. It contains information such as an organization’s name, the organization that issued the certificate, the users’ email address and country, and users public key. When a server and a client require a secure encrypted communication, they send a query over the network to the other party, which sends back a copy of the certificate. The other party’s public key can be extracted from the certificate. A certificate can also be used to uniquely identify the holder.

The advantage of Asymmetric encryption is that it does not force the user to share (secret) keys as symmetric encryption does, therefore removing the necessity of key distribution and 3-rd party/communication channel risk. Asymmetric encryption supports digital signing (via Digital Certificates) which authenticates the recipient identity and make sure that message is not tampered in transit. The cons of Asymmetric encryption are that it is time-intensive and it requires considerably more effort. Furthermore, you can send encrypted message only if the other person has created key pairs which means the other person must be knowledgeable. Finally, if you lose your private key – you will lose it forever. The private key is irrecoverable which could create a whole series of new problems to deal with.

Encryption, encoding and hashing are techniques used for converting the format of data. Encryption is used for changing plain text into cipher text so that only authorized entities can understand it. Encryption deals with keys which are used to encrypt and decrypt the data. These keys are used to transform a simple text into a cypher text and the vice versa. Encoding is used for changing the data into a special format which makes it usable by external processes. Unlike encryption, the intention of encoding is not related to security. The message is encoded by using an algorithm or scheme. In hashing, the data is converted to a message digest or hash, which is usually a number generated from a string of text. Hashing is not reversible as encryption and encoding. The data is converted to a message digest or hash, which is usually a number generated from a string of text. These digests are important as one can easily match the hash of sent and received messages to ensure that both are the same and no tempering is done with the data.

ROT13 (rotate 13) is a specific implementation of the Caesar cipher where the shift is 13 places. Due to the basic Latin alphabet being 26 characters long this means that the direction of the shift does not matter, the result is the same in either direction. They key (13) can be used without transformation.

A simple Caesar cipher transforms each letter of a plaintext message by shifting it a set number of places in a set direction along the basic 26 character Latin alphabet. The encryption and decryption here is not reciprocal as the key must be transformed (-3 to +3) to alter the direction of the shift when moving between encryption and decryption.

A typical PKI includes the following key elements: A trusted party, called a certificate authority (CA), acts as the root of trust and provides services that authenticate the identity of individuals, computers and other entities A registration authority, often called a subordinate CA, certified by a root CA to issue certificates for specific uses permitted by the root A certificate database, which stores certificate requests and issues and revokes certificates A certificate store, which resides on a local computer as a place to store issued certificates and private keys

A public key infrastructure (PKI) supports the distribution and identification of public encryption keys, enabling users and computers to both securely exchange data over networks such as the Internet and verify theidentity of the other party. Without PKI, sensitive information can still be

encrypted (ensuring confidentiality) and exchanged, but there

would be no assurance of the identity (authentication) of the other party. Any form of sensitive data exchanged over the Internet is reliant on PKI for security.

Consider the simple encryption of shifting every letter one to the right in the alphabet, so that A becomes B, B becomes C, and so forth. So that: HELLO becomes encrypted as: IFMMP I can shift one letter to the right, two letters to the right, or up to 25 letters to the right. Consider the "number of letters to the right" as the "key". It takes 5 bites to hold a number between 0 and 25. Therefore, the key size is "5 bits". The problem with a 5 bit key is that it only has 32 combinations. If I know the encryption algorithm, I can try all 32 keys until I find the right combination. The larger the key, the harder this becomes - EXPONENTIALLY. For symmetric algorithms (symmetric encryption, Message Authentication Code), a key is a sequence of bits, such that any sequence of the right length is a possible key. For instance, AES is a symmetric encryption algorithm which is defined over keys of 128, 192 and 256 bits: any sequence of 128, 192 or 256 bits can be used as a key. For asymmetric algorithms (also known as public-key cryptography, encompassing asymmetric encryption, digital signatures, some key exchange protocols, and a few more esoteric algorithms), keys work by pairs consisting in a public key and a private key. These keys are mathematical objects with some heavy internal structure. The "key length" is then a conventional measure of the size of one of the involved mathematical objects. For instance, a RSA public key contains a big integer called the modulus, as well as an other integer (usually small) called the public exponent. When we say a "1024-bit RSA key", we mean that the modulus has length 1024 bits, i.e. is an integer greater than 21023 but lower than 21024. Such an integer could be encoded as a sequence of 1024 bits, i.e. 128 bytes.

Consider the simple encryption of shifting every letter one to the right in the alphabet, so that A becomes B, B becomes C, and so forth. So that: HELLO becomes encrypted as: IFMMP I can shift one letter to the right, two letters to the right, or up to 25 letters to the right. Consider the "number of letters to the right" as the "key". It takes 5 bites to hold a number between 0 and 25. Therefore, the key size is "5 bits". The problem with a 5 bit key is that it only has 32 combinations. If I know the encryption algorithm, I can try all 32 keys until I find the right combination. The larger the key, the harder this becomes - EXPONENTIALLY. For symmetric algorithms (symmetric encryption, Message Authentication Code), a key is a sequence of bits, such that any sequence of the right length is a possible key. For instance, AES is a symmetric encryption algorithm which is defined over keys of 128, 192 and 256 bits: any sequence of 128, 192 or 256 bits can be used as a key. For asymmetric algorithms (also known as public-key cryptography, encompassing asymmetric encryption, digital signatures, some key exchange protocols, and a few more esoteric algorithms), keys work by pairs consisting in a public key and a private key. These keys are mathematical objects with some heavy internal structure. The "key length" is then a conventional measure of the size of one of the involved mathematical objects. For instance, a RSA public key contains a big integer called the modulus, as well as an other integer (usually small) called the public exponent. When we say a "1024-bit RSA key", we mean that the modulus has length 1024 bits, i.e. is an integer greater than 21023 but lower than 21024. Such an integer could be encoded as a sequence of 1024 bits, i.e. 128 bytes.

I have seen this done for video game releases. Customers are allowed to download an encrypted copy of the game in advance. Then, when the release time comes, the game company simply releases the key. That way, people can start playing immediately when the game is released, without needing to wait for a download.

Or (all answers are valid):

1. You may be interested in time-lock puzzles. The idea is to be able to make a problem instance that is easy to build but expensive to open, where the cost is configurable. Of course this does not guarantee a release at a specific date; rather, it guarantees a minimum effort to unlock the puzzle. Conversion between effort and date depends on how hard attackers try. In other words, if an attacker wants to get your file earlier, he just has to buy a faster computer.
2. Time is relative, but the speed of light is absolute. Put the decryption key sufficient distance away from the attackers. No powerful computer can overcome that. For example, you can use a mirror at some x/2 light years away, and then transmit the key to that mirror. Assuming no-one is able to sniff/disturb it, you'd have the appropriate delay of x years.
3. Carefully place a spaceship broadcasting the decryption key in orbit around a black hole. The pull of gravity will delay the message until the appropriate time.

SSL (and its successor, TLS) is a protocol that operates directly on top of TCP. This way, protocols on higher

layers (such as HTTP) can be left unchanged while still providing a secure connection. Underneath the SSL layer,

HTTP is identical to HTTPS. When using SSL/TLS correctly, all an attacker can see on the cable is which IP and port you are connected to, roughly how much data you are sending, and what encryption and compression is used. He can also terminate the connection, but both sides will know that the connection has been interrupted by a third party.

1. After building a TCP connection, the SSL handshake is started by the client that sends a number of specifications: which version of SSL/TLS it is running, what ciphersuites it wants to use, and

what compression methods it wants to use. 2. The server checks what the highest SSL/TLS version is that is supported by them both, picks a ciphersuite from one of the client's options (if it supports one), and optionally picks a compression method. 3. After this the basic setup is done, the server sends its certificate. This certificate must be trusted by either the client itself or a party that the client trusts. Having verified the certificate and being certain this server really is who he claims to be (and not a man in the middle), a key is exchanged. The client tells the server that from now on, all communication will be encrypted, and sends an encrypted and authenticated message to the server. 4. The server verifies that the MAC (used for authentication) is correct, and that the message can be correctly decrypted. It then returns a message, which the client verifies as well. 5. The handshake is now finished, and the two hosts can communicate securely.

No. MD5 is not encryption (though it may be used as part of some encryption algorithms), it is a one way hash function. Much of the original data is actually "lost" as part of the transformation. Think about this: An MD5 is always 128 bits long. That means that there are 2128 possible MD5 hashes. That is a reasonably large number, and yet it is most definitely finite. And yet, there are an infinite number of possible inputs to a given hash function (and most of them contain more than 128 bits, or a measly 16 bytes). So there are actually an infinite number of possibilities for data that would hash to the same value. The thing that makes hashes interesting is that it is incredibly difficult to find two pieces of data that hash to the same value, and the chances of it happening by accident are almost 0. MD5 has been found to have some weaknesses, such that with some complex mathematics, it may be possible to find a collision without trying out 2128 possible input strings. And the fact that most passwords are short, and people often use common values (like "password" or "secret") means that in some cases, you can make a reasonably good guess at someone's password by Googling for the hash or using a Rainbow table. That is one reason why you should always "salt" hashed passwords, so that two identical values, when hashed, will not hash to the same value. Once a piece of data has been run through a hash function, there is no going back.

A Root SSL certificate is a certificate issued by a trusted certificate authority (CA). In the SSL ecosystem, anyone can generate a signing key and sign a new certificate with that signature. However, that certificate is not considered valid unless it has been directly or indirectly signed by a trusted CA. A trusted certificate authority is an entity that has been entitled to verify that someone is effectively who it declares to be. In order for this model to work, all the participants on the game must agree on a set of CA which they trust. All operating systems and most of web browsers ship with a set of trusted CAs.

Hash Functions provide a mapping between an arbitrary length input, and a (usually) fixed length (or smaller length) output. A hash function could be considered the same as baking a loaf of bread. You start out with inputs (flour, water, yeast, etc...) and after applying the hash function (mixing + baking), you end up with an output: a loaf of bread.

Going the other way is extraordinarily difficult - you can't really separate the bread back into flour, water, yeast - some of that was lost during the baking process, and you can never tell exactly how much water or flour or yeast was used for a particular loaf, because that information was destroyed by the hashing function (aka the oven). Many different variants of inputs will theoretically produce identical loaves (e.g. 2 cups of water and 1 tsbp of yeast produce exactly the same loaf as 2.1 cups of water and 0.9tsbp of yeast), but given one of those loaves, you can't tell exactly what combo of inputs produced it. Encryption Functions provide a 1:1 mapping between an arbitrary length input and output. And they are always reversible. The important thing to note is that it's reversible using some method. And it's always 1:1 for a given key. Encryption could be viewed as a safe deposit box. Whatever you put in there comes back out, as long as you possess the key with which it was locked up in the first place. It's a symmetric operation. Given a key and some input, you get a certain output. Given that output, and the same key, you'll get back the original input. It's a 1:1 mapping.

Confusion means that each binary digit (bit) of the ciphertext should depend on several parts of the key, obscuring the connections between the two. The property of confusion hides the relationship between the ciphertext and the key. This property makes it difficult to find the key from the ciphertext and if a single bit in a key is changed, the calculation of the values of most or all of the bits in the ciphertext will be affected. Confusion increases the ambiguity of ciphertext and it is used by both block and stream ciphers. Diffusion means that if we change a single bit of the plaintext, then (statistically) half of the bits in the ciphertext should change, and similarly, if we change one bit of the ciphertext, then approximately one half of the plaintext bits should change.[2] Since a bit can have only two states, when they are all re-evaluated and changed from one seemingly random position to another, half of the bits will have changed state. The idea of diffusion is to hide the relationship between the ciphertext and the plain text. This will make it hard for an attacker who tries to find out the plain text and it increases the redundancy of plain text by spreading it across the rows and columns; it is achieved through transposition of algorithm and it is used by block ciphers only.

These two properties help to ensure that extracting the key from plaintext-ciphertext pairs is difficult or infeasible.

Symmetric Encryption is the simplest kind of encryption that involves only one secret key to cipher and decipher information. Symmetric encryption is an old and best-known technique. It uses a secret key that can either be a number, a word or a string of random letters. It is a blended with the plain text of a message to change the content in a particular way. The sender and the recipient should know the secret key that is used to encrypt and decrypt all the messages. Blowfish, AES, RC4, DES, RC5, and RC6 are examples of symmetric encryption. The most widely used symmetric algorithm is AES-128, AES-192, and AES-256. The main disadvantage of the symmetric key encryption is that all parties involved have to exchange the key used to encrypt the data before they can decrypt it.

Consider, for example, the simple encryption of shifting every letter one to the right in the alphabet, so that A becomes B, B becomes C, and so forth. So that: HELLO becomes encrypted as: IFMMP I can shift one letter to the right, two letters to the right, or up to 25 letters to the right. Consider the "number of letters to the right" as the "key". It takes 5 bites to hold a number between 0 and 25. Therefore, the key size is "5 bits". Now, the problem with a 5 bit key is that it only has 32 combinations. If I know the encryption algorithm, I can all 32 keys until I find the right combination. The larger the key, the harder this becomes - EXPONENTIALLY. A 6 bit key has 64 combinations, a 7 bit key has 128 combinations, and so forth. A 10 bit key has a thousand combinations, a 20 bit key has a million combinations, a 30 bit key has a BILLION combinations. Let's say that you have a computer that can test a billion keys per second trying to brute force all combinations. That means you can break a 30 bit key in just one second. But, that means it will take you a billion seconds (or 34 years) to break a 60 bit key. Every 30 bits we add makes it a billion times more difficult. A spy agency like the NSA can crack 60 bit keys using supercomputers, but a 90 bit key is a billion times more difficult to crack, and a 120 bit key would be a further billion times more difficult to crack than a 90 bit key. That's why older WEP (40 bits) and DES (56 bits) are considered obsolete: we can crack them with desktop computers by trying all combinations. That's why modern crypto, such as AES, uses 128 bits. We can't brute force crack those algorithms.

Without asymmetric encryption, the Internet as we know it would not exist, period. You can't sell stuff to random client systems with symmetric encryption. Why? For symmetric encryption to work means that you and your intended recipient both must know the key and keep it secret. So as a merchant ideally you have to have unique secret key for ALL your customers, plus transport and store it somewhere securely. Otherwise, if someone else knows the key (say another customer), then they can decrypt your data and read it, which makes the entire encryption process pointless.

With asymmetric encryption as a customer you just have to remember only public keys, and that is easy because public keys are public, so they can be "remembered" by being published somewhere, where everybody can see and use them. The Internet without asymmetric encryption would be like TV, where you look at the infomercial but you have to call in on the phone to make the purchase and verify you call to the right place.

Every cryptographic hash function is a hash function. But not every hash function is a cryptographic hash. The ideal cryptographic hash function has six main properties:

1. Deterministic: the same message always results in the same hash;
2. Quick: it is quick to compute the hash value for any given message;
3. One-way function: it is infeasible to generate a message from its hash value except by trying all possible

messages;

4. Avalanche effect: a small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value;
5. Collision resistant weak collision resistance (given a message m1 it must be difficult to find a different message m2 so that m1 and m2 yield the same hash) strong collision resistance (it should be difficult to find any messages m1 and m2 that yield the same

hash)

6. Pre-image attack resistant: given a hash h it must be difficult to find a message m that yields h when hashed. A cryptographic hash function should resist attacks on its pre-image. Non cryptographic hash functions just try to avoid collisions for non malicious input. In exchange for weaker guarantees they are typically (much) faster.

A salt is a fixed-length cryptographically-strong random value that is added to the input of hash functions to create unique hashes for every input, regardless of the input not being unique. A salt makes a hash function look non-deterministic, which is good as we don't want to reveal password duplications through our hashing. The reason that salts are used is that people tend to choose the same passwords, and not at all randomly. Many used passwords out there are short real words, to make it easy to remember, but this also enables for a dictionary attack (Using a pre-arranged listing of words, such as the entries from the English dictionary, with their computed hash, the attacker easily compares the hashes from a stolen passwords table with every hash on the list. If a match is found, the password then can be deduced). Salting is pointless if you don't have a separate salt for each user. The point of salts is to make breaking the hashes a separate task for each user password; if the salt is the same for all of them then that's not the case.

In cryptography, hash functions provide three separate functions.

1. Collision resistance: How hard is it for someone to find two messages ( any two messages) that hash the same.
2. Preimage Resistance: Given a hash, how hard is it to find another message that hashes the same? Also known as a one way hash function.
3. Second preimage resistance: Given a message, find another message that hashes the same. These properties are related but independent. For example, collision resistance implies second preimage resistance, but not the other way around. For any given application, you will have different requirements, needing one or more of these properties. A hash function for securing passwords on a server will usually only require preimage resistance, while message digests require all three.