Tag Info

12

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

9

If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable. And in fact, if you do not use the ...

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

6

The 16-byte IV and ciphertext (which together are part of the output of $e_m$) are assumed to be intercepted by an adversary. That reveals the number $b$ of 16-byte blocks in the ciphertext. With CBC and PKCS#7 padding, $b=\big\lceil{{n+1}\over16}\big\rceil$ where $n$ is the byte size of the plaintext (the file size). Putting $n$ itself in a header thus ...

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

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

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

I wrote a rather lengthy answer on another site a few days ago. Bottom-line is that CTR appears to be the "safest" choice, but that does not mean safe. The block cipher mode is only part of the overall protocol. Every mode has its quirks and requires some extra systems in order to use it properly; but in the case of CTR, the design of these extra systems is ...

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

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

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

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

4

Your problem is that if you encrypt two messages which start the same (and change at some point later on) the beginning of the ciphertext will be the same in CBC mode when using the same IV. Normally you should change the IV every time you encrypt a new message. This is precisely what the IV is meant for - achieving IND-CPA (semantic) security which ...

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

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

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

The IV for a block cipher in CBC mode must not only be "uniquely used for each message encrypted with the same key". It is usually assumed to be indistinguishable from random by an adversary. If the IV is predictable, some attacks apply. For example, if an attacker is able to choose plaintext messages with prior knowledge of what the IV will be for this ...

3

Assuming: the objective is to protect the confidentiality of the user names from an attacker having read access to the encrypted data, the ability to add usernames of her choice, and nothing else (in particular, no access to the key, even by proxy of a computer or device holding the key, or side channel); the IV is randomly chosen for each individual ...

3

Sure, that's fine, but you're really just using the first block of ciphertext as the IV. If you choose the first plaintext block to be a running message counter (which you might as well do; it's easier than generating a random block) and your "discarded IV" to be all zeros (or vice versa) then your method is equivalent to standard CBC mode combined with the ...

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

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

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

2

The proper precautions, this is an acceptable way to implement CBC (and yes, it interoperates with the more traditional implementation of CBC, at least, implementations of CBC that put the IV immediately in front of the ciphertext). The proper precaution is to make sure, in the encrypt direction, that the value of the iv exclusive-or'ed with the block of ...

2

You are hoping to get integrity protection by applying CBC mode; the problem with this is that CBC mode isn't great at providing integrity protection. One way an attacker can exploit this, if he guesses what the plaintext is, he could modify block N of the plaintext to anything we wants by changing block N-1 of the ciphertext. This will modify block N of ...

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