Here, we will explore the theory behind symmetric key encryption. This is encryption, where both parties can send secure messages to each other with some shared (and private) key.
Sometimes, we call symmetric key encryption schemes ciphers.
By the end, we will have built the theory behind the symmetric key schemes used in the internet today.
One of the driving principles behind symmetric key encryption is as follows:
Kerckhoffs' Principle
A good cipher scheme should be able to be public, without adversaries being able to use it to decrypt messages. To do this, both parties share a secret key for encryption / decryption which adversaries are assumed to not know.
Secure schemes do not get their security from being poorly defined.
We always have to assume that the crypto designs are public! This is more suitable for large-scale usage of cryptography, and exposes schemes to the public eye so that they can be revised and strengthened.
Historical Ciphers
Let’s first examine some historical schemes before going into the theory.
For each of the following historical schemes, we will discuss the encryption algorithm, the decryption algorithm, the key-space (set of all possible keys) and secret key, and how to break the scheme.
Atbash Cipher
The Atbash Cipher substitutes the first letter with the last, the 2nd with the 2nd last, and so on. To encrypt and decrypt, simply swap the letters.
Because there is nothing that is secret, there is no key for this algorithm.
Shift / Caesar Cipher
The Caeser Cipher replaces each letter by the letter which is positions away in the alphabet. On a message, this has the effect of “shifting” every letter positions in the alphabet.
As there are 26 letters in the alphabet, there are 26 possible shifts we could do. Thus, our key-space has a size of 26.
Because the key-space is so small, we can easily brute-force this cipher by trying all possible shifts! Thus, this cipher is suspectible to a brute-force search.
For a secure scheme, it’s necessary that the key space is large! However, a large key space does not imply security.
Scytale Cipher
The Scytale Cipher stacks letters of the message into equal-sized rows. Reading the message column-by-column will give you the ciphertext (encryption), and reading the message row-by-row will give you the plain-text (decryption).
As we could have a nearly infinite number of rows, the key-space is arbitrarily large!
That does not make this cipher secure however, as we may be able to recover the key! Starting from the first letter, we can take letters that are offset positions from the start, to try to form a word. Once we get something that makes sense, we’ll have recovered our key!
Information about our ciphertext can let us reverse engineer the key!
Monoalphabetic Substitution
The Monoalphabetic Substitution maps every plaintext letter to a different ciphertext character, and substitutes them as so. Using this map, we can encrypt and decrypt our message.
The size of our key-space is , which is really large! So, brute force search is not possible, but because of the 1-1 mapping, we could do a frequency analysis to recover the key!
Frequency Analysis
Frequency analysis is based off the fact that letters in (gramatically correct) English generally have different usage frequencies. If we know the frequencies of the ciphertext characters, we can guess what the mappings are.
Symmetric Key Encryption
Formal Definition
A symmetric encryption scheme is defined by 3 algorithms: Gen
, Enc
, Dec
. Let be our message space, with .
Gen
: The key-generation algorithm (typically probabilistic), which creates a key according to some distribution (must be probabilistic).- denotes the keyspace, the set of all possible keys.
Enc
: The encryption algorithm, which takes an input key and message to create ciphertext (could be probabilitic).- denotes the ciphertext space, the set of all possible ciphertexts.
Dec
: The decryption algorithm, which takes an input key and ciphertext to create message (must be deterministic).
Correctness mandates that . If this does not hold, our encryption scheme won’t be very practical.
Each of the spaces can be given as random variables with probability distributions. Let denote the probability function. Then:
- denotes the probability that the key output by
Gen
yields .Typically, we will assume that has the uniform probability distribution (each key is of equal probability)
- denotes the probability that the message is equal to , modeling some prior knowledge the adversary may have about the message.
- denotes the probability that the ciphertext is , which is fully determined by the distribution on , , and
Enc
.
We assume that the distributions over and are independent.
Perfect Secrecy
We say an encryption scheme over a message space is perfectly secret if probability distributions over , such that ,
In other words, the probability that our message is does not change even if we know what the ciphertext is. Sometimes, we denote as the a priori distribution, and as the a posteriori distribution.
This means that seeing does not give us any information about the message space!
There are a few equivalent definitions to perfect secrecy.
Equivalence 1
An encryption scheme over a message space is perfectly secret if and only if probability distribution over , , ,
In other words, this is saying that the ciphertext is independent of the message (as we can still vary the key ).
Proof (One-Way)
Suppose that we have a perfectly secret scheme. We wish to show that is also true.
Fix message distribution , , . By definition, we know that the following must hold by perfect secrecy.
and by Baye’s Rule,
Equivalence 2: Perfect Indistinguishability
An encryption scheme over a message space is perfectly secret if and only if probability distribution , , and ,
Example: Perfect Secrecy Example
An encryption scheme with message space is perfectly secret if and only if probability distribution over , and , we have
Prove or refute this.
This is false. For every perfectly secret encryption scheme, we can always choose a distribution on for which this is false.
By way of contradiction, suppose this is true. Now, choose a distribution such that
Then, by definition of perfect secrecy,
Which is a contradiction!
Example: Perfect Secrecy Example (2)
An encryption scheme with message space is perfectly secret if and only if probability distribution over , and , ,
- Explain this definition in English.
- Why is this a bad definition? Describe an encryption scheme that leaks information about the message but still satisfies the definition.
Seeing the ciphertext does not tell us any information about the key.
This is bad, because we could just choose an encryption scheme with only one key, so it’s completely deterministic! For example, we do a shift cipher with only possible key . Then, for any ciphertext, , but we can easily reverse the encryption scheme.
Another solution is, this definition says nothing about the message! So, we could have a scheme that doesn’t do anything to the message (leaves it unencrypted), and generates a random key!
Example: Perfect Secrecy Example (3)
, . Gen() chooses a key at random from , , . Is this perfectly secret?
No. BWOC, suppose it is. Let , and let have the uniform distribution, and let . Then,
The One-Time Pad
Here, we describe a perfectly secret symmetric encryption scheme — the One-Time Pad. It works as so:
- Fix integer . are all equal to .
Gen
: Choose a string from according to the uniform distributionEnc
: Given , , output .Dec
: Given , , output .
Note that the notation stands for binary numbers (digits 0 or 1) of length .
Example: One-Time Pad Example
Let’s see an example of the one-time pad. Let , and suppose we have message , key .
One time pad encrypts the ciphertext by XORing the binary numbers.
011 XOR 101 = 110
! To decrypt, we XOR the ciphertext with our key again.
110 XOR 101 = 011
Theorem: OTP Secrecy
The one-time pad encryption scheme is perfectly secret.
Proof
Recall that a scheme is perfectly secret if for all distributions on , , ,
Fix distribution over , , .
For ,
Thus,
By perfect indistinguishability, OTP is perfectly secret.
The one-time pad is one of the few perfectly secret algorithms, and in fact, many schemes are variants / equivalent to the one-time pad. Thus, for proofs it’s often a good idea to start from the OTP and modify the scheme from there.
Example: Perfectly Secret Example
Prove or refute: An encryption scheme with message space is perfectly secret if and only if for every probability distribution over and every we have .
Not true. To show why, we will construct a perfectly secret scheme that violates this. To do this, we will start from the one-time-pad (this is a good technique).
For message of length , let’s take a key of length , where , with varying probabilities. Then,
stands for the concatenating of binary strings together.
Because of the biased bit, our ciphertexts do not have the same probability, but no information is released!
Formally, choose any distribution over , , where . Then,
The one-time pad is a powerful scheme, but it doesn’t come without its flaws:
- The key length is the same as the message length, so for every bit communicated over a public channel, a bit must be shared privately.
- This is an inherent problem in perfectly secret encryption schemes! We prove this in the following theorem.
- Key can only be used once.
This makes it very difficult to use the one-time pad in practice.
Theorem: Limitations of Perfect Secrecy
Let us have a perfectly secret encryption scheme over message space , key space . Then, it must be true that .
In most cases, this means that the lengths of the keys must be the same or longer than the lengths of our messages!
Proof
By way of contradiction, assume we have a perfectly secret encryption scheme where .
To obtain our contradiction, we must show that there exists a probability distribution , message , and ciphertext such that
Often, when contradicting perfect secrecy, we use the uniform distribution on .
Let have the uniform distribution. By perfect secrecy, for , ,
Let’s do a brute force search over the key-space. Let be the set of all messages . Because the decryption is deterministic, we have that (it can be smaller if multiple keys decrypt to the same message).
So, there exists some message that is contained in but not . Choose this message instead. Then,
This is a contradiction! So, our scheme cannot be perfectly secret.
Shannon's Theorem
Let
Gen, Enc, Dec
be an encryption scheme with message space , for which . Then, the scheme is perfectly secret if and only if:
Every key is chocsen with equal probability by
Gen
.For every , there exists a unique key such that .
Note that this only applies when ! If this condition is not true, then we cannot use Shannon’s Theorem.
Example: Shannon's Theorem Example
Let . Let choose a key at random.
Shannon’s theorem applies here! First, we know by assumption that all keys are chosen uniformly.
We also show that for , we explicitly can solve for a single such that . We find
The Computational Approach
Motivation
Shannon’s Theorem asserts that for correct schemes that are perfectly secret, . Thus, achieving perfect secrecy is, in many cases, unpractical for many real world situations.
Here, we explore a more relaxed definition for security, known as the computational approach. The computational approach only requires the following:
- Security is only guaranteed against efficient adversaries that run for some feasible amount of time.
- Efficient adversaries are adversaries that can run in polynomial time (we also call them PPT adversaries).
- Adversaries can potentially succeed with some very small probability.
- Adversaries can succeed, but they would need to run in non-polynomial time— they would run out of time if they were running in non-polynomial time.
We formally define these notions below.
Formal Definitions
Under the computational approach, schemes now have an additional parameter called the security parameter ().
Prior to running our scheme, we can set our security parameter, which tells us the run time of the adversary and its success probability as functions of . This gives a sort of guarantee against adversaries running in polynomial time.
We can think of the security parameter as the length of the key.
Efficient Adversaries
An adversary is efficient if they are in polynomial time (PPT). To be in polynomial time means that there exists some polynomial , such that the adversary runs for time at most when the security parameter is .
Example: Polynomial Time Functions
is a polynomial function in
is not a polynomial function in
is a polynomial function in
To know if a function is polynomial, it may help to take the log, and see if this is bounded below or above by (this is the logarithm of a polynomial!)
Given a security parameter , to say an adversary is running in time means that for , the adversary has that amount of time to run.
Negligible Probability
A small probability of success means we have a negligible probability. A function is negligible if for every polynomial , and sufficienly large , it holds that
In other words, as , the function is smaller than all polynomial functions.
The product of any polynomial with a negligible function is a negligible function!
To know if a function is negligible, take its reciprocal and see if its super-polynomial or not! If its reciprocal is a super-polynomial, then is negligible.
Example: Negligible Functions
- is negligible
- is not negligible
- is negligible
- is not negligible
Practical Implications of Computational Security
Why do we define computational security as so?
Let’s say for key size , any adversary running in time breaks the scheme with probability . Meanwhile,
Gen, Dec, Enc
take time .If , then
Gen,Enc,Dec
take time- Adversary runs in time !
If , then
Gen,Enc,Dec
take timeAdversary runtime is multiplied by ! Becomes .
This makes it really easy to adjust schemes to the adversary time! As adversary capabilities increase, we can shift our security parameter so that they will continue to be unable to break our scheme!
Private Key Encryption
A private-key encryption scheme is a tuple of probabilistic polynomial-time algorithms Gen, Enc, Dec
such that:
Gen
takes security parameter (1 repeated times), and outputs a key denoted . WLOG, assume .Enc
takes a key , message , and outpus a ciphertext , .Dec
takes a key , ciphertext , and outputs a message .
By correctness, we mandate that for every , every , and every , it holds that (the scheme must be deterministic).
Security in the Presence of an Eavesropper (EAV)
To define security under the computational approach, we think of an experiment.
Consider a private-key encryption scheme , any adversary , and any value for the security parameter. We define a random variable experiment
Where the adversary and our challenger play the following game:
- The adversary chooses two messages from the message space.
- The challenger will generate a key and choose randomly. Based on , the challenger then encrypts one of the messages .
- The adversary receives the ciphertext , and now has to guess , denoting which message they think was encrypted.
- We check if the adversary was right, and set the random variable to 1 if the adversary was right (), 0 if wrong ().
We say has indistinguishable encryptions in the presence of an eavesdropper (EAV-secure) if PPT adversaries , a negligible function such that
In other words, the adversary has close to a 50/50 chance of correctly guessing the message (as there are only 2 messages to choose from), with some negligible offset that drops to 0 quickly as ! This tells us that they don’t really get any information about the message!
This is a weak notion of security and is not very useful in practice!
Similar to the different definitions of perfect secrecy, computational security also has equivalent definitions— though these other definitions are outside of the scope of this class.
Pseudorandom Generator (PRG)
Here, we define a pseudorandom generator. These can be used to create schemes that are computationally secure, with (making the scheme more practical).
Recall that this wouldn’t be possible for perfect secrecy!
A pseudorandom generator (PRG) is a deterministic algorithm , that takes as input a short random seed , and outputs a longer string . It has the property that no polynomial time algorithm can “distinguish” from a truly random string , despite being a deterministic function.
What this generator essentially does is “stretch” a small amount of true randomness () to a larger amount of pseudorandomness, without compromising on security.
To have a PRG, we also define a game.
- Ideal World: We sample a truly random bit string of length , . It must hold that , where is called the expansion factor (’s output must be longer than the input).
- Real World: We sample a truly random bit string of length , and compute .
- We give either the ideal world or real world bit string to , the distinguisher. For a PRG, any efficient distinguisher cannot tell which “world” the string is from (if it got or ).
Formally, the probability that the distinguisher guesses the ideal world is about the same in either case.
This means that the distinguisher has no way of really knowing which is the ideal world!
Here, only gets bits of true randomness, but need to “stretch” that randomness to bits!
Given a PRG, we can only assume the following:
- If our input random string is uniform, the PRG’s output will also be uniform.
Example: PRG Proof (1)
Let be a PRG where .
Let , where is the negation of . Is a PRG?
We know that is not uniformly random, as depends on . Because the input is not random, we cannot assume is a PRG.
Let’s construct a pathological example. Let’s construct from another PRG, , which is a function from as so:
We must show that is a PRG, and is not a PRG. Let’s start with .
- is a PRG, as if forms a truly random string, then are random, and is also random. So, , being a PRG on a uniformly random input, outputs a uniformly random output.
- , but by the deterministic nature of PRGs, we have the same string concatenated with itself! So, the output does not have a uniform distribution.
Formally, define a distinguisher , which get some input . We choose a polynomial time algorithm for which lets it distinguish randomness from the PRG with non-negligible probability.
One algorithm could do is split the string in half, return 1 (PRG output) if the halves are the same, 0 otherwise. With this algorithm, we have the following probabilities:
- , as we will always be able to tell the PRG as its two halves are always the same (shown above)
- , as for any string in the first half we need to match it in the second half.
So,
This is not a negligible function, as when increases this goes to 1! So, we can define a constant function which this is greater than as .
So, we have a that breaks the security of
Using PRGs, we can create a secure fixed-length encryption scheme that is secure, and breaks the Shannon bound. Let be a PRG taking , , and let .
Gen
outputs a random key .Enc
takes the key, runs it through the pseudo-random generator to get a pad . It then XORs the output with the message to get our ciphertext .Dec
reverses this by XORing the same pad with the ciphertext.
This is a computationally-secure scheme, and , breaking the Shannon bound! We can prove this below.
Proof
We wish to show that given is a PRG, our scheme is EAV-secure. So, PPT adversaries, such that
In many cryptographic proofs, we cannot prove the definition directly. So, we prove by contradiction or contrapositive.
So, we will show that if PPT adversaries such that ,
Then cannot be a PRG.
Let be this adversary. Then, PPT distinguisher such that there exists a non-negligible function , where
Given this distinguisher, we will contruct another distinguisher against the PRG, that uses as a subroutine.
This is based off proof reduction! The idea that if one algorithm solves the boolean satisfiability problem, then it can be used to solve all NP-complete problems in polynomial time!
- is a distinguisher that needs to take a string , and needs to return 0, 1 guessing what world the string came from. It contains and can use
- is an adversary that will first send to the challenger (). It expects a ciphertext, and guesses if is an encryption of or .
This is almost an algorithm! We just need to fill it in with a few steps.
- How does generate the challenger ciphertext for ?
- randomly chooses a , and sends back .
- After getting the response from , , what response does output?
- If , then return 1
- If , then return 0
We now analyze the probabilities to show that our PRG is not actually a PRG.
- The probability is the probability guesses correctly if . This is
- The probability is the probability that guesses the one-time pad, which (by perfect secrecy) is
As no matter what guesses, it cannot do better or worse by perfect secrecy.So,
As is non-negligible, breaks the security of the PRG. Because is a PPT, is also a PPT as it uses , we are done.
However, this compuationally secure scheme is not very practical.
- The length of the message is fixed
- The scheme can only be used once, as if the same key is used twice, the scheme would no longer be secure!
Stream Ciphers
To make something that can be used in practice, recall that for two PRGs, inputting the output of one into another will still yield a pseudo-random string! So, if we chain these PRGs together, we’ll get a “stream” of unique keys we can encrypt with.
This is the idea behind the stream cipher.
- Let be a PRG that takes as input and outputs .
- Let represent some initial state, which is a truly random key.
Both the sender and receiver will store a state, which will let them generate a pseudorandom stream of 0s and 1s to use in a one-time pad. For every application of the PRG, the 1st bit will be used for the one-time pad, and the remaining bits will be used as the next state.
Then, for some message, we can generate the ciphertext for the bit as
Both the sender and receiver are in sync (so long as they have the same initial key), so the receiver can decrypt the ciphertext with the same pad!
Because the stream cipher does not use the same key, we have a secure scheme that can be used to send multiple variable-length messages! However, this requires that the sender and receiver are in sync— if any bit is dropped, then they won’t be in sync and the decryption will fail.
Key Idea
It’s possible to use a PRG to create a practical encryption scheme, with the cavaet that the sender and receiver need to share a state!
Chosen Plain-Text Attack Security (CPA)
Computational security was a bit of a weak and limited notion. Here, we define a notion that can actually be used in practice.
This notion can be used for multiple messages, and is a very standard notion of security!
Consider a private-key encryption scheme Gen, Enc, Dec
, any adversary , and any value for the security parameter.
We define the following experiment, .
- The challenger (sender / receiver) will generate some key .
- The adversary gets oracle access to the encryption algorithm, denoted . This means that does not know , but gets to use the encryption scheme. They’re allowed to choose a plaintext message and get back a ciphertext , for as many messages as they want (in polynomial time).
- When the adversary has sampled enough input-output pairs, it sends two messages to the challenger.
- The challenger picks a bit at random, and based on this chooses one of the messages to encrypt .
- After receiving the ciphertext, gets oracle-access to the encrpytion scheme to query again.
- When ready the adversary outputs , guessing what message the challenger chose.
- if , and 0 if .
We say our scheme has indistinguishable encryptions under a chosen-plaintext attack (CPA-secure) if for all PPT adversaries , there exists a negligible function such that
While this is a one-shot game, we can prove that CPA-security gives us security for multiple encryptions!
Theorem
Any adversary that has indistinguishable encryptions under a CPA-attack also has indistinguishable multiple encryptions under a chosen plain-text attack!
This means that we can use CPA-secure schemes with the same key, as many times as we want while maintaining security!
Info
If the adversary is allowed to query the oracle, what is stopping the adversary from just querying ? They could just query and see what the ciphertext is!
Because of this, any scheme that satisfies CPA-security must necessarily be probabilistic, meaning when we call the oracle, the ciphertext for any given message will be different.
This motivates the following theorem.
Theorem
If is an encryption scheme where
Enc
is a deterministic function of the key and the message, then cannot be CPA-secure.Proof
Let be an adversary.
- chooses two messages .
- query its oracle to get .
- sends to the challenger and gets back .
- If , predicts . Otherwise, predicts .
Clearly, is efficient as it only queries the oracle once, which is polynomial.
Furthermore, will always win the game with probability 1, which is greater than .
Pseudorandom Functions
We will use pseudorandom functions to create schemes that are CPA-secure! As it does not make sense for a fixed function to be pseudorandom, we will define pseudorandomness on our selection from a set of fixed functions.
A keyed function () is a two-input function, where
- The first input is the key, denoted .
- The second input is .
We say is efficient if there is a polynomial-time algorithm that can compute given and . We will only be interested in efficient pseudo-functions.
is public and polynomial-time efficient.
Let be a PPT distinguisher. We define the following experiment:
- gets access to an oracle which is either equal to ( chosen at random) or , a uniformly chosen random function. ( does not know which is the case).
- is a function with input set , and for each input one output in . Then, to choose uniformly at random, uniformly assign one output from to each input. After being chosen, it then behaves deterministically.
- may query the oracle for any , at which point the oracle returns .
- Because the oracle computes a deterministic function, it returns the same result if queried twice on the same input.
- may interact freely with the oracle, denoted , choosing its queries based on the outputs (as long it runs in polynomial time).
- returns 1 if it thinks the oracle is our pseudorandom function , 0 otherwise.
Then, a keyed function is pseudorandom if for all PPT distinguishers , there exists a negligible function such that
In other words, for any polynomial-time distinguisher, the probability that the distinguisher guesses that our function is the pseudorandom function (1) is negligible.
, for uniform key , is indistinguishable from a function chosen uniformly at random from the set of all functions with the same domain and range ().
To disprove that a function is a PRF, the question is: can we find a set of inputs whose outputs are correlated?
Example: Pseudo-Random Functions (Disproof)
Let be a PRF. For , show if is a PRF.
Suppose we plug in the following values of .
Notice how the second half of the first input, and first half of the second input are the same! Thus, these two inputs have correlated outputs, and the distinguisher could use this fact to determine if it has the PRF or not. It can query these two inputs, and return 1 if these halves are the same!
With this attack,
The probability for the truly random function comes from the fact that we need all bits of half of the second output to match the first, and under a uniform distribution, this is probability .
Example: Pseudo-Random Functions (Proof)
Let be a PRF. For , show if is a PRF.
This is a PRF! To see why, think of the input/output table for .
Because of the bit in front, we’re partitioning the input space of ! So, there will never be any collision where the same query yields correlated outputs. Thus, this PRF is secure.
Show that the space of inputs to are partitioned, and as is a PRF there will be no collisions. An intuitive argument is acceptable for this course.
CPA-Security with PRFs
Like with PRGs, we will now use PRFs to construct a CPA-secure scheme.
Let Gen
output a random key , chosen uniformly randomly. Also, let be a pseudorandom function.
- Choose a random string .
- Use the random string with to create a pad, .
- With this pad, XOR it with our message to get . Let be our random string. Then, our ciphertext is given as .
- We need the random string in the ciphertext to be able to decrypt our message.
Intuitively, this is secure because despite knowing , we don’t know , and the security of PRFs guarantee that without knowing , we cannot differentiate from a random function!
Theorem
If is a pseudorandom function, then the construction above is a CPA-secure private-key encryption scheme for messages of length .
Proof
We will prove this via contrapositive (as typical of these proofs). Suppose the construction above is not CPA-secure. Then, some PPT and non-negligible function such that
We wish to show that is not a pseudo-random function. In other words, that distinguisher and non-negligible function such that
Define a distinguisher , who has within it. is playing a PRF game; is playing a CPA-security game.
- gets an oracle , talks to the oracle, and returns 0/1 indicating if it thinks the oracle is the PRF.
- can make queries to the oracle, sends to get , makes queries again, and then guesses 0/1 indicating what message it thinks is from.
So, would do the following:
- First, gets an oracle which is either or .
- will now choose a random string .
- will be allowed to query the encryption scheme as needed. To query, will take ’s message, query , and return to .
- now take , and send them to .
- will randomly choose , choose a random message based on this, and encrypt this as shown above. It sends this back to .
- will return an answer . If , then output 1. Otherwise, output 0.
In the case that ,
As it is the same probability as when guesses correctly.
In the case that ,
As this is the one-time pad game with probability 1/2, but there is exactly 1 case where can guess correctly, which is if the same is chosen when generating the challenger ciphertext and in a CPA-query. In this event, guesses correctly 100% of the time.
stands for the number of CPA queries, and gives us a bound on this event happening.
And as a non-negligible minus a negligible is non-negligible, this is some non-negligible function. Thus, our function is not a PRF.
Pseudo-Random Permutations
A pseudorandom permutation is exactly the same as a pseudorandom function, except that for every key , must be a permutation and it must be indistinguishable from a random permutation.
Permutation means, every function is a bijection! So, on the truth table, every input has a 1-1 mapping to a unique output, where every output has an input!
So, for the input-output table, each output appears exactly once!
This means that pseudo-random permutations are invertible! Furthermore, if you know the key, it should be possible to efficiently invert it!
Using pseudo-random permutations, we can define the following scheme.
- The challenger chooses a random key from the key-space. This chooses a pseudo-random permutation.
- The adversary gets oracle , which is either the pseudo-ranodm permutation , or a truly random permutation .
- A truly random permutation is one where for each output , it randomly gets assigned to one input !
- The adversary can query the oracle in the forward and backward direction, which is either , or .
- The adversary guesses what function the oracle is.
A strong pseudo-random permutation (PRP) is one in which any efficient adversary cannot tell which world the oracle belongs to.
There are possible permutations from .
PRPs are also known as block ciphers.
Previously, we created a CPA-secure encryption scheme for 1 block messages. We can now use PRPs to create a scheme that can encrypt multiple blocks!
Let message have the following blocks . How can we encrypt this message?
- One way we could do this is by running the 1-block scheme times! This is okay in terms of security, but wastes a lot of resources!
- We need to generate a random key every time, which could be costly
- Every block needs the random ciphertext concatenated with it, doubling the size of each ciphertext block! This uses a lot of data.
The various ways we can use PRPs to encrypt blocks of messages are known as modes of operation. They are described below.
-
Electronic Code Block (ECB): Encrypt each message block with the PRP, and concatenate them together.
To decrypt, simply run the inverse of the function on each ciphertext block.
This is not a secure scheme, as it will give us the same output for the same input. However, it is intuitive and makes a lot of sense!
-
Cipher Block Chaining (CBC): Start with some initialization vector , a truly random bit-string. Then, for every block, we can compute its ciphertext as
In other words, to get our next ciphertext, we XOR the block with the previous ciphertext and run it through the PRP.
To decrypt, run the inverse on the ciphertext, and XOR it with the previous ciphertext.
-
Output Feedback (OFB): Start with some initialization vector . Then, to generate the ciphertext, we will first generate keys by repeatedly running the through the PRP.
Then, we XOR the key with our message block to get our ciphertext.
To decrypt, we repeat the key-stream and XOR each key with the ciphertext.
-
Counter (CTR): Start with some random number which will serve as a counter, . Then, to generate the ciphertext, we will run through the PRP and XOR the output with the message. Increment counter after each message block.
To decrypt, we repeat the same process.
2,3,4 all achieve similar levels of security!
In looking at each mode, we should also think about if the mode is parallelizable!
Practical Constructions for Block Ciphers
How do we construct strong PRPs (block ciphers) in practice?
Below, we’ll discuss some various ideas that were uesd to define PRPs. Suppose we’re working with a 128-bit input and 128-bit output.
By the end, we’ll end on how AES-128 works.
For each idea, we’ll ask the questions:
- Does the construction give us a permutation (does each input have a unique output)?
- Is the construction indistinguishable from a random permutation (secure)?
Substitution-Permutation Networks (SPNs)
Here’s an idea:
Shannon Confusion Paradigm
Over small enough domains, random permutations are efficient. For example, if we only need to generate a random permutation table for an 8 bit output, we only need to generate entries!
So, what if we could extend this? For a 128-bit input, let our key specify 16 permutations on 8-bit blocks. Then, for an input , break it into 8-bit blocks , and generate ciphertext
- This is a permutation, as we can invert ciphertext by taking .
This is good, but is not indistinguishable from a truly random permutation. To see why, query two messages, where only one block is different. Then, every output block between the two messages should be the same except block .
This fails because the order of the blocks is fixed which exposes information. We add an additional step to address this, where we permute the ordering of the blocks.
This is known as the Shannon Confusion-Diffusion Paradigm! The first step is known as confusion, and the block re-ordering step is known as diffusion.
A practical implementation of this paradigm is known as the Substitution-Permutation Network (SPN). An SPN applies the following operations, in what’s known as a round:
- Key Mixing: The message is XORed with key , which is derived from the master key.
- A different key is used each round, and is derived from the master key using a key schedule (which often just takes different subsets of the master key’s bits).
- Substitution: The message is split into blocks, and each block is ran through an S-Box, fixed and public permutations on some -bit input and -bit output.
- Permutation: The bits are permuted through a public mixing function.
The SPN runs multiple of these rounds to obtain an output that looks random. After running each round, the network will always finish by running one more final key-mixing step.
Note that the substitution and permutation functions are completely public! The security comes from the keys that are XORed with the message at the key mixing steps.
How many rounds are needed for this to be secure?
Theorem: The Avalanche Effect
For a random permutation, when a single input bit is changed, we should expect each bit of should be changed with probability 1/2. So,
- We design S-boxes so that changing a single bit of the input to an S-box changes at least 2 bits in the output of the S-box
- We design the mixing function so that the output bits of any given S-box are used as input to multiple S-boxes in the next round
Because of this, on round , if 1 bit of the input is changed, we can expect it to influence bits of the output. So, for AES-128, we need at least 7 rounds () for this to hold / give us the security we need!
In the case that we don’t have enough rounds, it’s possible to break SPN with a key-recovery attack. Suppose we have oracle access to our SPN.
Example: Key Recovery Attack vs. 1-Round SPN
Suppose we have a 1-round SPN on 16-bit messages, using 4-bit S-boxes, where our key is length 32-bit ( used for the first mix, used for the second).
Using a brute-force approach, there are possible key values! However, we can actually significantly reduce this.
To understand why, suppose we queried the oracle to get input output pair . For any , there exists 1 unique that gives us . So, an attacker could do the following:
- Query the oracle for .
- For a 16-bit block of , guess one of the combinations.
- Invert the SPN for our message (XOR y with , inverse mix, inverse S-box, then XOR with x) to find the corresponding for this .
- Now, query the oracle for another message, and see if our pair gives us the correct message.
This means we only need to evaluate the SPN times! This is a lot more efficient than our original brute-force approach.
However, we could actually do even better than this! The key to this is realizing that we can actually compute our combinations for each S-box block at a time.
- Take some S-box block, say the block for to .
- Figure out the bits of the output (and ) which are the output of this S-box block (XOR these bits of with the guess, inverse S-box, then XOR with the block for ).
- Now, for any given block, we need to guess possible bit combinations of to find the corresponding for that block!
Repeating this for each of the 4 blocks, we now only evaluate our SPN times to get 4 lists, which represent all possible outputs of ! We can run this on extra messages to determine which key combination is correct.
AES
Advanced Encryption Standard (AES) essentially uses the SPN paradigm for security.
Feistel Network
Feistel Networks are another way we can generate block ciphers, though we will not cover it in the sake of time.
Feistel networks essentially take a PRF, and convert it into a secure PRP.
DES
Data Encryption Standard (DES) uses the Feistel Network.
Message Authentication Codes (MAC)
In the previous section, we discussed how to create a secure encryption scheme. However, security is not everything! Even without knowing the original message in the previous schemes, attackers can still modify the message with no way for the sender / receiver to tell.
In other words, there’s secrecy, but not integrity! In this section, we will discuss how we can create schemes that maintain integrity.
Secure MACs
Suppose we have a sender, receiver, and eavesdropper, where only the sender and receiver have knowledge of the . Say the sender doesn’t care about security, and just wants the receiver to be able to verify that the message came from them, and was not modified in transit. How can they do this?
They do this using a message authentication code (MAC) scheme .
- Both the sender and receiver share a key randomly generated with
Gen
. - The sender runs a MAC Algorithm , which generates a tag that can be used for authentication.
- The sender sends the message and tag together, , to the receiver.
- The receiver runs a Verification Algorithm , which returns 1 (valid) or 0 (invalid) indicating if the message was sent by the sender or not (based on if the tag matches the message).
Corectness guarantees that . In other words, the verify algorithm should always work if the message truly wasn’t modified.
Like before, we will formalize this scheme with an experiment
Let be a MAC scheme, be an adversary, and be the security parameter. Let the challenger play the part of the sender / receiver.
- The challenger first generates a random key .
- gets oracle access to the MAC algorithm, . In other words, they can query any message they want, and get back a tag for that message. Let be the set of all messages queried by .
- tries to forge the message authenticity, by sending message and tag pair to the challenger.
- The adversary wins, , if:
- . In other words, the adversary did not query and get the tag for (if they queried , this is known as a replay attack, which has to dealt with separately in practice).
- . In other words, the challenger was tricked into finding the tag matches the message
We say is existentially unforgeable under an adaptive chosen message attack if PPT , negligible function such that
Note that unlike security, this probability must be less than negligible probability, not .
For shorthand, we will just say the scheme is secure in this case.
Strong Security
There’s also a stronger notion of security for MAC schemes, which we’ll call strong security. In this case, is the set of all message, tag pairs , and the adversary wins if
In other words, the adversary is allowed to replay a message, as long as the tag is different.
In practice, we don’t worry about this too much as the schemes we use are deterministic, so there’s only one valid tag per message (so strong security and normal security are the same).
Example: MAC Disproof
Suppose we have a MAC, where for mesage , , choose at random and compute .
This is, in fact, not a secure MAC. We can show this below.
Let be an adversary which does the following:
- Suppose we have some message we want to authenticate. Query the oracle to get the tag .
- From the tag , take random bit-string in the beginning.
- Now create forgery, where is the message where each block of the message is XORed with from above. Let be the tag where is our random bit-string, with after.
This is a valid forgery, which gives us a non-negligible probability of breaking the MAC!
Constructing Secure MACs (Fixed-Length)
We can construct secure MACs using pseudorandom functions!
Let be a pseudorandom function. We define a fixed-length MAC for messages of length as follows:
Gen
: Outputs a random key .Mac
: For key and message , output .Vrfy
: For key , message , tag , output 1 if and only if .
This only works for fixed-length messages. Later, we’ll use this to create schemes that work for variable length messages.
Theorem: MAC Security
If is a PRF, then the construction above is a secure fixed-length MAC for messages of length .
Proof
By contrapositive, suppose the construction is not a secure MAC. So, there exists a PPT adversary , non-negligible function , such that
We must show that there exists a distinguisher such that
For non-negligible function .
Let do the following, playing the PRF experiment.
- Let get the oracle, which is either random function , or .
- gives oracle access. For any MAC query from , forwards messgae to the oracle to get and sends it back to .
- When ready, sends to as a forgery.
- checks if , output 0. If , forward to the oracle and check if . If so, output 1, 0 otherwise.
Note that is running , so is running in PPT. We have the following probabilities.
Which is non-negligible. Thus, is not a PRF.
Constructing Secure MACs (Variable-Length)
Let’s see how we can extend MACs for variable-length MACs, known as domain extension for MACs.
Suppose we have a MAC , which works for fixed-length messages of length . For a message of any length,
How can we generate a tag for this message?
Naive Extension
One way we could do this is by running each block of the message through the MAC to get a tag for each block.
Unfortunately, this is not secure. This is because there’s nothing “tying” the blocks of the messages together— so, an adversary can easily reorder the blocks to break the security of the scheme.
Let’s see some ways we can extend the MAC.
CBC MAC
CBC-MAC: We generate one tag by running each message through , XORing the result with the next message, and repeating this process. Formally,
This is secure only if the message and forgery are both required to have a fixed length ! If these conditions are relaxed, we can perform a length extension attack to break the security of the MAC— let’s see how below.
Example: Length Extension Attack
Suppose the message and forgery are not required to have block-length . Then, let be the adversary who queries two messages of length 3 blocks each. will use these messages to then generate a forgery on a 6 block message .
- can query , to get tag .
- Then, can query to get tag .
- This tag is our forgery! Return forgery where .
This creates a forgery that breaks the security of our MAC!
This happens because we’re allowed to query the oracle on a prefix of the previous message. This relation breaks the security.
To fix CBC-MAC, we will first instead start the MAC not on , but on some prefix-free encoding. This is a scheme that maps an input message into a space of valid code-words, where for any two valid code-words, one does not prefix the other.
One easy way to do this is by encoding the length of the message! So, CBC-MAC would do the following:
The prefix-free encoding ensures that messages cannot prefix each other in the MAC scheme!
Essentially, what we are doing is prepending an extra message block to the message, which indicates its length.
Hash and MAC
Hash-And-Mac: Using a hash function to compress messages of arbitrary lengths to the MAC input size. We use the hsah function to compress the message, then create a mac from the fixed-size output.
Formally, a hash function (with output length ) is a pair of PPT algorithms Gen
, H
satisfying the following:
Gen
takes input security parameter and outputs a key .H
takes input key , string and outputs a string
If is only defined for inputs and , then we say that Gen
, H
is a fixed-length hash function for inputs of length . In this case, is also called a compression function (shrinks the size of the input).
We define the following experiment, .
- Generate key by running .
- The adversary is given and outputs .
- The output of the experiment is 1 if and only if , and .
We say a hash function is collision resistant if for all PPT adversaries, there exists a negligible function such that
With hash functions, we can easily create MACs for variable length messages! We first hash our message into the MAC input domain, and then run the MAC algorithm
Theorem
If is a secure MAC for messages of length , and is collision resistant, then the construction above is a secure MAC for arbitrary length messages.
Proof (Sketch)
Suppose by way of contradiction there is an adversary breaking Hash-And-Mac. We show that under this assumption, this adversary can break either the securei MAC or the hash function.
If can break the scheme, then it can produce , .
- Case 1: We can check the list of queries to find , which will yield for some and . This will break the collision resistant hahs function.
- Case 2: In all the queries in , they all correspond to different inputs to . This will break the MAC.
But how do we create a compression function in practice?
Creating a Compression Function in Practice
One way we can create a compression function is by using the Davies-Meyer Construction.
Let be a block cipher with -bit key and -bit block length. Then, for bit message , we can compress the message as
Note that the XOR with is necessary, as without it, we could easily generate a collision (’s key is known, so we can decrypt on a different key to find a different message, key pair).
Intuitively, this works because the output of looks “random”, so it serves as a bit-mask on . This will modify arbitrarily, giving us a “random” looking output.
Security is guaranteed only if we assume is not a PRP, but an ideal cipher, meaning that queries are allowed only on different keys that are not .
Given a compression function with fixed input-output lengths, we can then extend it to accept variable-length inputs using the Merkle-Damgard Transform (used by SHA-1 and SHA-256):
- Split the message into blocks of equal length: .
- Take an initialization vector, .
- Hash for every to get .
- Finally, hash , where is the length of the message.
In practice, the initialization vector is something hard-set, like .
This works as long as our function is a compression function (output is smaller than the input)!
We need to pad with the length, to distinguish messages that aren’t perfectly aligned with the blocks. If we were to pad these messages with 0s instead, we could easily create a collision.
Theorem: Security of Merkle-Damgard
If the underlying compression function is collision resistant, then so is , the Merkle-Damgard Transform of this function.
Proof (Sketch)
We wish to show (by contrapositive) that if we can find a collision in , say , we can generate a collision for .
Case 1: If the length of the two messages are not equal, we can easily create a collision on by taking the last inputs to in the transform. So, our collision is given by and .
Case 2: If the lengths are equal, check if . If they’re equal, repeat this case for and . If they are not, we have two messages generating a collision.
There must be some , as otherwise, the messages are the same (which is a contradiction).
Merkle-Damgard is not a secure MAC.
Constructing a for Merkle Damgard
For a hash function outputting bits, to get a collision with 100% probability, we need to try inputs (by pigeon hole principle).
However, we don’t need 100% probability of success to make the function insecure! By the birthday bound, we really only need to find a collision with a reasonable probability. So, regardless of how good our collision function is, an attacker only needs about samples to break the security!
The birthday bound states that for uniform, independent, random samples of , we have collision probability bounded by
Because of this, has to be pretty large.
For example, as SHA-1 outputs length , someone could break it in time queries.
Sponge Construction
Sponge: Recently, a new paradigm has emerged for domain extension. Let be a completely random permutation on .
This is the paradigm used in SHA-3.
Using , we will first absorb the input in one stage, then squeeze out the output in another (this is why it’s known as a sponge).
- Absorb:
- Start with an internal state of all 0’s, split into an section and a section. In other words, our state starts as .
- For every block of the message , XOR it with , and run . The first bits is our new section, with the rest being the section.
- Repeat this for all blocks of the message, until the entire input is absorbed.
- Squeeze:
- Take the first bits of the state, and output them.
- If more bits are needed, run the state through and output the next bits.
is our bitrate, how fast we can absorb / squeeze data; is our capacity, how secure our method is.
It can be shown that if is our key , and the remaining are our message blocks, this sponge method can be used directly as a MAC; it is indifferentiable from a random oracle, if is a truly random permutation.
Authenticated Encryption
CCA Security
We’ve seen a secure way to encrypt our message for security, and a secure way to authenticate our message for integrity. Now, let’s tie the two together!
Chosen Ciphertext Attack (CCA) Security is a standard security notion, which is even stronger than CPA security. We define the following game.
Consider a private-key encryption scheme , some adversary , and security parameter . Define the following experiment
- The challenger generates a key .
- The adversary gets oracle access to both the encryption and decryption algorithm, . They can query messages to get ciphertexts, and ciphertexts to get messages.
- The adversary chooses 2 messages, and sends them to the challenger.
- The challenger chooses one of the messages at random, , encrypts it, and sends the ciphertext of back.
- The adversary can again query the encryption and decryption oracle. When ready, it returns guessing what message was encrypted.
- To make sure this game is possible, in this step, the adversary is NOT allowed to query challenge ciphertext to the decryption oracle. It can query anything else though, as long as it is not . We’ll denote this slight limitation as
- The experiment is 1 if , 0 otherwise.
We say has indistinguishable encryptions under a chosen-ciphertext attack (CCA secure) if PPT adversaries , a negligible function such that
This is a really strong notion of security!
Authenticated encryption schemes satisfy this type of security, by using MACs to tag the ciphertext for authentication. Then, throws an error (denoted ) if it detects an invalid ciphertext. By doing this, the adversary can only decrypt the ciphertexts its seen, and can’t make its own!
Unforgeability for Encryption
To define an authenticated encryption scheme, we also need to define an additional experiment :
- Run
Gen
to obtain key - The adversary is given input , and access to the encryption oraacle . The adversary outputs a ciphertext .
- Let , and let denote the set of all queries that queried from the oracle. The output of the experiment is 1 if and only if and .
We say a private-key encryption scheme is unforgeable if PPT adversaries , there is a negligible function such that
Authenticated Encryption Schemes
We say a private-key encryption scheme is an authenticated encryption scheme if it is CCA-secure and unforgeable.
This is essentially a secure way of combining CPA-security and MACs!
Here are some generic constructions.
Encrypt and Authenticate
Encrypt-and-Authenticate: We run encryption and message authentication independently, in parallel.
Do NOT use the same key for both schemes.
preserves security, and preserves privacy, but combining them does not guarantee both! This is because the tag can leak info on , which will break the security of the message.
In fact, if the MAC is deterministic (which it often is in practice), then CPA-security does not hold for the combined .
Authenticate then Encrypt
Authenticate-then-Encrypt: We first generate a tag, then compute our ciphertext by combining our message with the tag.
Now, because we’re putting our tag into the ciphertext, this can provide privacy. However, this will not provide CCA-security!
Encrypt then Authenticate
Encrypt-then-Authenticate: We first encrypt the message, and then compute a tag on the result.
This is secure as long as the MAC is strongly secure! Because only the encryption scheme sees the message, it provides CPA-security, and the use of the MAC preserves privacy, without compromising on security!
This also gives us CCA-security, as it renders the decryption oracle useless, as it will only return unless a known ciphertext from CCA-security is given (and we’re not allowed to query the challenge ciphertext ).
This is exactly what goes on in the internet after key establishment!