# Tag Info

14

There's no need for an IV when unique keys are used. When each key is used only to encipher a single message, it is safe (from a confidentiality standpoint) to use null IV for all messages. That's customary, for all common modes requiring an IV. It avoids the need to generate an IV, and transmit it, and (in the case of CBC) perform a XOR of the first block ...

7

If you could use the same IV, then yes, you would need to rewrite everything after the modified block. But you shouldn't do that; every time the contents change, you should generate a new IV, which would require the whole file to be rewritten. Otherwise an attacker can learn more information than it should about how the file changed (precisely by checking ...

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: ...

6

In their 2012 paper "The Security of Ciphertext Stealing", Phillip Rogaway, Mark Wooding and Haibin Zhang prove that all the NIST-approved ciphertext stealing modes provide the same level of security as ordinary CBC mode, i.e. ciphertext indistinguishability under a chosen-plaintext attack. To quote their abstract: "Abstract. We prove the security of ...

6

In a scenario such as yours, where there is only one password/passphrase, but it is used as key material for the encryption of multiple CBC encrypted files, you will (as you noted yourself) obviously not make it any harder for an attacker to compute your password, should you use a salt. However, using a salt would mean that the encryption of each file is ...

6

As already given as partial answer in the comments, you would have to leak the second block as an IV is normally transmitted without confidentiality. You could of course retrieve it from initially decrypting the ciphertext without IV, and retrieve the first block value later on. But using an encrypted IV has got it's own vulnerabilities. The other issue is ...

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

All looks pretty secure except for your auth key derivation. You should use a better key derivation method like HKDF instead of just SHA-512. I don't think your random nonce is doing anything in this scenario - an attacker who wants to brute-force a weak password wouldn't be slowed down by a nonce transmitted in the clear. Why not just use a ...

5

TLS 1.0 uses initialization vector (IV) to refer to two different processes. TLS 1.1 introduces a new type of IV that causes an entire block to be discarded and isn't directly comparable to the old series of IVs based on CBC residue. By simply changing an operation at the beginning of a record, the hope was apparently to make implementations easy to patch ...

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

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 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 ... 4 The 1/2^{32} is an arbitrary figure, based upon one particular value for what counts as an acceptable risk. You need to decide what is an acceptable risk. If you think that a 1/2^{32} probability of failure is an acceptable risk, then this calculation is relevant to you. If you think it isn't, then decide what you think is an acceptable risk and re-do ... 4 Yes, this is fine, at the record level. (What you've built would be classified as a "Encrypt-then-Authenticate" scheme in the literature, and there are standard provable security results for such schemes.) Well done on constructing a solid, well-engineered cryptographic scheme. An AEAD mode would spare you from having to invent such a scheme, but what ... 4 No, the scheme described in the question does not provide integrity. A forgery is possible when the message's size is allowed to vary (which is presumably the case since some padding is used), and the adversary can choose some segment of the message with knowledge of the message before that segment. That is, a message M=M_b||M_c||M_d with the beginning ... 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 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 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 ... 3 The #1 thing you can do is: don't derive your keys as a function of a password/passphrase. That's a security breach just waiting to happen. Using something like scrypt mitigates the risk somewhat, but by no means does it eliminate the risk. This is likely to be the weakest link in your cryptographic scheme. Instead, use a truly random value as your ... 3 Sadly, there's no uniform answer to this. The answer will depend upon your specific application domain. In some application domains, revealing the exact length of the plaintext is not a problem. In other application domains, it is a very serious problem. There's no one-size-fits-all answer. That's probably why you don't find much discussion of this. ... 3 Designing an HSM or other secure device is relatively easy; making it reliable even in the absence of adversary requires careful engineering; making it safe against adversaries with some level of physical access is hard; demonstrating that it is safe (for some definition of that) is even harder. One thing to worry about is integrity of stored data ... 3 16 bytes is 128 bits, which matches the block size of AES-256, but not "256 bit block" in the (original) title. Hence the question is ambiguous: was it meant 16, or 32 bytes? For 16 bytes: ECB reduces to single-block encryption, and yes ECB is safe, for a definition of safe that let one test identity of plaintexts by testing identity of the ciphertexts. ... 3 If you know that the integer is fixed in size (always in the range 1-1000), then the second approach is fine. Effectively, you still have a random nonce (what you are calling the "junk"); you concatenate the nonce and the integer, then encrypt the result with AES-ECB. This works. Do make sure that you choose a large enough random nonce. I recommend ... 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 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 ... 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 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, ... 2 Bit padding, PKCS#5 padding and PKCS#7 padding are always applied, and they are always applied to the end of the plaintext. The last block of ciphertext will always contain the padding. The padding is always 1 to [blocksize] bytes, which in case of AES is 1 to 16 bytes. For PKCS#5 padding and PKCS#7 padding - which are basically identical - the value of the ... 2 Since the counter values are not authenticated, an attacker can try to swap the order of messages in order to modify things. If a message arrives out of order, the MAC will be correct, since the ciphertext has not been modified, but after decryption, the first block of message will be messed up and the rest of the message left intact. Will this be enough to ... 2 Just to be sure we're on the same page, I interpret your question as defining encryption of a string P_1 P_2 \cdots P_\ell with a counter \mathsf{ctr}, key K, and an n-bit blockcipher E as follows:$$ \mathcal{E}_K(\mathsf{ctr}, P_1P_2\cdots P_\ell) = C_0 C_1 C_2 \cdots C_\ell where $C_0 = E_K(\mathsf{ctr})$, $C_{i+1} = E_K(C_i \oplus P_{i+1})$, ...

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