# Tag Info

7

CBC mode encryption is defined as: $C_i = E_k(P_i\oplus C_{i-1})$ (with $P_i$ being the $i$th plaintext block, and $C_{i-1}, C_i$ being the ciphertext blocks. What might happen if we have a lot of ciphertext encrypted with the same key is if two ciphertexts happen to be the same, that is: $C_i = C_j$ If we see that, we can then immediately deduce that: ...

5

Let me see if I have this right (and please correct me if I misunderstand; my conclusions depend on the details of this); you distribute images for your firmware device; these images are encrypted with a secret AES key (using AES in CBC mode); the device decrypts the image, and then runs that decrypted image. The sole check to make sure that the image ...

5

The reason why CBC is considered better than ECB has nothing to do with situations involving an attacker with a partial ciphertext; we always assume that any attacker has full access to the ciphertext. Instead, the problem with ECB is that it leaks information. Specifically, if you encrypt two messages which has two blocks of plaintexts in common, then ...

5

Absolutely. The key point is that, whilst in CBC mode, the encryption can be thought of as using the previous ciphertext as the IV - have a look at this diagram from wikipedia: I assume from what you've said that you have a function that will "do" AES-CBC decryption on large amounts of data, and you wish to use this. So, you simply run: $$D_k^{IV}(c_1\ ... 5 Well, yes, it does matter; however the terminology 'CBC-MAC' does not specify which. CBC-MAC is a generic construction that takes an arbitrary block cipher, and turns it into an object that acts like a MAC for fixed length messages (much like CBC mode is a generic construction that takes an arbitrary block cipher, and turns it into a object that encrypts ... 5 Yes, your MAC is secure. It's probably not quite as secure as you're expecting it to be, and it's not a construction I would recommend to anyone, but it should be secure. Let's start with a simpler variant: F_K(M) = E_K(H(M)) where H(\cdot) is a 128-bit collision-resistant hash (say, the first 128 bits of SHA1) and where E_K(\cdot) is a 128-bit ... 5 With CBC mode the initialization vector is referred to as IV, because it is not nonce. There are ways to construct nonce so that it does not meet the needs of CBC mode. Random IV is one generation choice which is usually fine. Nonce can also be a counter, which is not ok here. Definitions Nonce means number used once. IV means initialization vector. CBC ... 4 Here's a nice paper I came across a while ago: Wooding, Mark (2008), "New proofs for old modes", Cryptology ePrint Archive, report 2008/121: "Abstract: We study the standard block cipher modes of operation: CBC, CFB, and OFB and analyse their security. We don't look at ECB other than briefly to note its insecurity, and we have no new results on counter ... 4 Well, there is no really good way; the encryption of the plaintext is E_k( Plaintext \oplus IV) (followed by 16 bytes which are a deterministic function of the first ciphertext block). The AES function E_k is designed to be totally unpredictable if you don't know the key, there's nothing to leverage there. The only thing that allows you to gain any ... 4 Yes. Assume that the attacker knows the ciphertext c = c_1 \mathbin\| c_2, the initialization vector v and the plaintext m = m_1 \mathbin\| m_2. This tells them that D_k(c_1) = m_1 \oplus v and D_k(c_2) = m_2 \oplus c_1, where D_k(\cdot) denotes block cipher decryption under the (unknown) key k. In particular, this implies that, if the ... 4 Normally you don't want to reverse the encryption used within a DRBG. Schemes like PKCS#7 padding and CTS are required to deterministically reverse the padding during decryption. If you just want to have a final block, you should be fine by using zero padding until the end of the block. Of course, if this zero padding is actually harming the output of your ... 4 From the sound of your questions, it almost appears that you have some confusion between the CBC-MAC key and the CBC-MAC tag. The CBC-MAC algorithm takes the message (in this case, most likely the ciphertext) and a secret key; it outputs a tag (which can be public). The security property of CBC-MAC is that someone who does not know the key cannot generate ... 3 Just for completeness sake, CBC is defined as follows: The error you have made is that:$$M;N = (M_1, ..., M_n, N_1 ⊕ \mathbf{T_m}, N_2, ..., N_n) (I've changed notation from M||N to M;N to reflect this isn't just concatenation) You need to cancel the tag from the message $M$, not the tag from the $N$ message. In that case, $T_{M;N}=T_N$ as required.

3

The usual mode for disk encryption is XTS (let's say the mode suggested by the NIST). AEAD cipher seems to be promissing but typically with the GCM you will have also to store an authentication tag per encrypted block which may lead to a complex implementation (but interesting). I believe that regarding at least integrity, there exist "new" file systems ...

3

My first thought was that I could set the IV to the first 8 bytes of the CT [and] decode the rest[.] This is exactly how CBC works. For all blocks but the first, encryption is defined by $C_n=E_K(C_{n-1}\oplus P_n)$ and, therefore, decryption is achieved by $P_n=C_{n-1}\oplus D_K(C_n)$. Since there is no previous ciphertext for the first plaintext ...

3

The classic proof is contained in http://www.cs.ucdavis.edu/~rogaway/papers/sym-enc.pdf (1997), but it is not quite easy.

3

If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV. And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA). Why? Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is ...

3

First of all, I suggest you to try use as IV first 16 bytes of encrypted file. Because in general IV is the first block of ciphertext. But if that doesn't work, then – of course – you can decrypt all message except first block. Just use first block as IV, and start to decrypt from second block. That will work because CBC does not provide integrity, and ...

3

Remark: in One Time Pad the pad is used once, thus this is not OTP, since here $k$ is reused. Hint for part 1: Write the relations between $k$, the message blocks $m_i$, the ciphertext blocks $\small C_i$ with the convention $\small\text{IV}=\small C_0$. Then, find equations that allow computing the desired $m_3⊕m_4$ from known quantities. Hint for part 2, ...

3

To see the problem, let's see how I would chain up a single function (call it $AES\,CBC_k(iv, m)$) which only encrypts a single block at a time into something that can encrypt "chunks" of any size. Let $m=m_1||m_2||m_3||m_4$ be the message I want to encrypt. Each $m_i$ is a single block (in AES it is 128 bits). I want to use $AES\,CBC_k$ to encrypt $m$. The ...

3

You should use random IV even when unique keys are used. This prevents key-collision attack where the attacker collects number of cryptograms that have been encrypted with unique keys and brute-forces for key. Using predictable IV will reduce security of your cryptosystem by a factor of N (where N is the number of ciphertexts created). The attack recovers ...

3

You should read the wikipedia article about disk encryption. In short: for disk encryption, data is organized in sectors (for instance of size 512 bytes), and data may be encrypted with a chaining mode of operation such as CBC only inside these sectors, using a different initialization vector for each sector.

3

Well, if you have hardware which you can give it a long ciphertext block, and say "decrypt this block in one shot", well, one could argue that reusing the last ciphertext block as the next IV might give some minimal amount of gain; you would concatinate all the ciphertexts in order, and ask for the hardware to decrypt the entire thing -- the result will be ...

2

Yes, your understanding is correct. With the CBC-MAC's of $(a), (b)$ and $(a||b)$ you can forge the following new messages: $(a||b \oplus MAC(a)), \\ (b||a \oplus MAC(b)), \\ (b||b \oplus MAC(b)),\\ (a||a \oplus MAC(a)),\\ (a||b||a \oplus MAC(a||b)), \\ (a||b||b \oplus MAC(a||b)), \\ (a||b \oplus MAC(a)||a \oplus MAC(b))\\ (a||b \oplus MAC(a)||b \oplus ... 2 In the padding oracle attack you have an oracle that only tells you whether a particular chosen ciphertext decrypts to a correctly padded plaintext. That oracle is used to build a last word oracle, which used iteratively can reveal a whole message. The reason it works in CBC mode is that we can make predictable, arbitrary changes to the plaintext of the ... 2 …are any other modes of operation vulnerable to padding oracle attacks? Nope, it’s purely restricted to CBC. A padding oracle attack, also known as “Vaudenay attack” because it was originally published by Serge Vaudenay in 2002 and introduced at EUROCRYPT 2002, is an attack against cipher-block chaining. The attack works against any block cipher in ... 2 If the last 16 bytes of the ciphertext are the padding, then you actually have the simple ECB (Electronic CodeBook) mode. ECB is secure as long as all your plaintexts are 1 block long and never repeat. 2 Depending on how malleability is defined, the question actually has some merit. Given to the Wikipedia definition of malleability, a cipher is malleable if there exists at least one function$g$over the set of possible cipher texts, and one function$f$over the set of possible plain texts, such that given any cipher text$c_0$, the cipher text$c_1 = ...

2

It is insecure to reuse the $IV$ with AES-CBC. At the very least, if the files have a common prefix, this will be revealed as a common prefix of the ciphertexts. For AES-CBC, the only way to ensure confidentiality is to use random $IV$s. However, if you are not restricted to a particular CBC mode, the nonce-based Counter mode (CTR) might solve your problem. ...

2

There is not much difference and in practice the terms are often used to mean the same thing. In this context however the Nonce does not have to keep to the random properties that the IV has. As explained in the paper: A probabilistic encryption scheme $C = \varepsilon^R_K (P)$ is an IV-based encryption scheme, syntactically, but we are suggesting that, ...

Only top voted, non community-wiki answers of a minimum length are eligible