diff --git a/src/stream-ciphers.rst b/src/stream-ciphers.rst index 3762bc71..05296dfb 100644 --- a/src/stream-ciphers.rst +++ b/src/stream-ciphers.rst @@ -333,19 +333,19 @@ information, the server that handles it encrypts it using a strong block cipher in :term:`CBC mode` with a fixed key. For now, we'll assume that that server is secure, and there's no way to get it to leak the key. -Mallory gets a hold of all of the rows in the database. Perhaps she did +Mallory gains access to all rows in the database. Perhaps she did it through a SQL injection attack, or maybe with a little social engineering. [#]_ Everything is supposed to remain secure: Mallory only -has the ciphertexts, but she doesn't have the secret key. +has the ciphertexts, but not the secret key. .. [#] - Social engineering means tricking people into things they shouldn't - be doing, like giving out secret keys, or performing certain - operations. It's usually the most effective way to break otherwise + Social engineering means tricking people into doing things they should not + be doing. For example, giving out secret keys or performing certain + operations. It is usually the most effective way to break secure cryptosystems. Mallory wants to figure out what Alice's record says. For simplicity's -sake, let's say there's only one ciphertext block. That means Alice's +sake, let's say there is only one ciphertext block. This means Alice's ciphertext consists of an IV and one ciphertext block. Mallory can still try to use the application as a normal user, meaning @@ -375,27 +375,31 @@ The server dutifully encrypts that message using the predicted IV & = E(k, IV_A \xor G) \end{aligned} -That ciphertext, C\ :sub:`M`, is exactly the ciphertext block Alice -would have had if her plaintext block was G. So, depending on what the -data is, Mallory has figured out if Alice has a criminal record or not, -or perhaps some kind of embarrassing disease, or some other issue that -Alice really expected the server to keep secret. +The ciphertext, C\ :sub:`M`, is exactly the ciphertext block Alice +would have if her plaintext block was G. Depending on the +data, Mallory found out if Alice has a criminal record or not, +or some kind of embarrassing disease, or some other issue that +Alice really expects the server to keep secret. -Lessons learned: don't let IVs be predictable. Also, don't roll your own -cryptosystems. In a secure system, Alice and Mallory's records probably -wouldn't be encrypted using the same key. +Lessons learned: do not let IVs be predictable. As we'll see later on in the +book, just having unpredictable IVs doesn't make a system safe! This is a +general argument against rolling your own cryptosystems: a high-quality +implementation might have encrypted those records under different keys. Or it +could use other controls, like relying on the associated data of an AEAD (which +we'll see later) to make sure processes wouldn't perform cryptographic +operations on behalf of Mallory that would also have worked for Alice. Attacks on CBC mode with the key as the IV ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Many CBC systems set the key as the :term:`initialization vector`. This seems -like a good idea: you always need a shared secret key already anyway. It -yields a nice performance benefit, because the sender and the receiver -don't have to communicate the IV explicitly, they already know the key -(and therefore the IV) ahead of time. Plus, the key is definitely -unpredictable because it's secret: if it were predictable, the attacker -could just predict the key directly and already have won. Conveniently, -many block ciphers have block sizes that are the same length or less +Some CBC systems set the key as the :term:`initialization vector`. This seems like +a good idea because you always need a shared secret key. It +yields a nice performance benefit because the sender and receiver +do not have to communicate to the IV explicitly. They already know the key +(and therefore the IV) ahead of time. Plus, the key is an +unpredictable secret. If it was predictable, the attacker +could just predict the key directly. Conveniently, +many block ciphers have block sizes of the same length or less than the key size, so the key is big enough. This setup is completely insecure. If Alice sends a message to Bob, @@ -403,15 +407,15 @@ Mallory, an active adversary who can intercept and modify the message, can perform a chosen ciphertext attack to recover the key. Alice turns her plaintext message :math:`P` into three blocks -:math:`P_1 P_2 P_3` and encrypts it in :term:`CBC mode` with the secret key -:math:`k` and also uses :math:`k` as the IV. She gets a three block -ciphertext :math:`C = C_1 C_2 C_3`, which she sends to Bob. +:math:`P_1 P_2 P_3`. It is encrypted in :term:`CBC mode` with the secret key +:math:`k`. :math:`k` is the IV. She gets a three block +ciphertext :math:`C = C_1 C_2 C_3` and sends it to Bob. -Before the message reaches Bob, Mallory intercepts it. She modifies the +Mallory intercepts the message before it reaches Bob. She modifies the message to be :math:`C^{\prime} = C_1 Z C_1`, where :math:`Z` is a block filled with null bytes (value zero). -Bob decrypts :math:`C^{\prime}`, and gets the three plaintext blocks +Bob decrypts :math:`C^{\prime}` to get three plaintext blocks :math:`P^{\prime}_1, P^{\prime}_2, P^{\prime}_3`: .. math:: @@ -433,22 +437,22 @@ Bob decrypts :math:`C^{\prime}`, and gets the three plaintext blocks & = P_1 \xor IV \end{aligned} -:math:`R` is some random block. Its value doesn't matter. +:math:`R` is a random block. Its value does not matter. -Under the chosen-ciphertext attack assumption, Mallory recovers that -decryption. She is only interested in the first block +Mallory recovers the decryption under the chosen-ciphertext attack assumption. +She is only interested in the first block (:math:`P^{\prime}_1 = P_1`) and the third block (:math:`P^{\prime}_3 = P_1 \xor IV`). By -XORing those two together, she finds -:math:`(P_1 \xor IV) \xor P_1 = IV`. But, the IV is the key, so Mallory -successfully recovered the key by modifying a single message. - -Lesson learned: don't use the key as an IV. Part of the fallacy in the -introduction is that it assumed secret data could be used for the IV, -because it only had to be unpredictable. That's not true: “secret” is -just a different requirement from “not secret”, not necessarily a -*stronger* one. It is not generally okay to use secret information where -it isn't required, precisely because if it's not supposed to be secret, +XORing the two together, she finds +:math:`(P_1 \xor IV) \xor P_1 = IV`. IV is the key, so Mallory +successfully recovers the key by modifying a single message. + +Lesson learned: do not use the key as an IV. Part of the fallacy in the +introduction is assuming secret data can be in the IV given +it only has to be unpredictable. This is not true: “secret” is +just a different requirement from “not secret”. It does not mean a +*stronger* one. Secret information should not be used when +not required. Precisely because if the secret is supposed to be secret, the algorithm may very well treat it as non-secret, as is the case here. There *are* plenty of systems where it is okay to use a secret where it isn't required. In some cases you might even get a stronger system as a @@ -458,24 +462,24 @@ what you're doing. CBC bit flipping attacks ~~~~~~~~~~~~~~~~~~~~~~~~ -An interesting attack on :term:`CBC mode` is called a bit flipping attack. Using -a CBC bit flipping attack, attackers can modify ciphertexts encrypted in -:term:`CBC mode` so that it will have a predictable effect on the plaintext. +A bit flipping attack is an interesting attack on :term:`CBC mode`. +A CBC bit flipping attack allows attackers to modify ciphertexts encrypted in +:term:`CBC mode`. The result is a predictable effect on the plaintext. -This may seem like a very strange definition of “attack” at first. The -attacker will not even attempt to decrypt any messages, but they will -just be flipping some bits in a plaintext. We will demonstrate that the -attacker can turn the ability to flip some bits in the plaintext into -the ability to have the plaintext say *whatever they want it to say*, -and, of course, that can lead to very serious problems in real systems. +Initially, this seems like a strange definition of “attack”. The +attacker does not attempt to decrypt messages, but +just flips some bits in a plaintext. Next, we demonstrate that the +attacker switches the flip of some bits in the plaintext into +having the plaintext say *whatever they want it to say*. +Of course, that leads to serious problems in real systems. -Suppose we have a CBC encrypted ciphertext. This could be, for example, -a cookie. We take a particular ciphertext block, and we flip some bits +Suppose we have a CBC encrypted ciphertext like +a cookie. We take a particular ciphertext block and flip some bits in it. What happens to the plaintext? -When we “flip some bits”, we do that by XORing with a sequence of bits, -which we'll call :math:`X`. If the corresponding bit in :math:`X` is 1, -the bit will be flipped; otherwise, the bit will remain the same. +When we “flip some bits”, we XOR it with a sequence of bits, which we will call +:math:`X`. If the corresponding bit in :math:`X` is 1, the bit flips; otherwise, +the bit stays the same. .. figure:: ./Illustrations/CBC/BitFlipping.svg :align: center