# 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

The most common way to transmit an initialization vector is, indeed, to prepend it immediately before the ciphertext. When you look at the original ciphermodes the first used IVs (CBC, CFB, OFB), the IV actually does function as a 'previous ciphertext block' for the very first actual ciphertext block; placing it immediately in front of the very first ...

7

Using a static IV isn't simply "poor form" — it introduces crippling weaknesses to the security of your ciphertexts. Likewise, using correctly-generated IVs (the requirements differ from mode-to-mode, but cryptographically random IVs almost always meet those requirements) isn't "better"; it's absolutely necessary. That said, there is absolutely no ...

6

The initialization vector is XORed against the first plaintext block before encryption in CBC mode, as shown in the Wikipedia article on block cipher modes. After the first block is decrypted, you still have an intermediate value which has been XORed with the plaintext — without this, you have little hope of recovering the plaintext. However, you do not need ...

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

As already mentioned by fgrieu in a comment, you seem to be mixing up the initialization vector for the cipher with the salt for the key derivation. They play similar roles — both are here to insure that different values of the IV/salt lead to different keys/ciphertext — but they are used in different ways and they have different security properties in this ...

5

The answer is that you can do exactly what you say. Initialize the counter to a random 16 byte number and start counting. Wikipedia (not sure if that is where you got the idea that it must be 8 bytes and 8 bytes) has the following note: The IV/nonce and the counter can be combined together using any lossless operation (concatenation, addition, or XOR) to ...

4

For all standard modes, AES isn't secure at all if you reveal the key; even if you keep the IV hidden. Exactly how this works out varies between modes; for CBC mode, the attacker will be able to decrypt the entire text except for the first block (well, last block because of your reversing the file), even if you didn't give him an IV. The same goes for CFB ...

4

Assuming the mod 11 check digit is among 0123456789X, disclosing it reduces the number of possible plaintexts among 8-digit numbers by a factor of about 11 (from 100000000 to about 9090909; exactly how much depends very slightly on the value of the check digit), thus reveals about $\log_2(11)$ bits of information about the plaintext, that is just a little ...

4

The entire block consists of a $n$ bit nonce and a $128-n$ bit counter. Typically $n=64$. The nonce needs to be large enough so that every message under the key can have a unique one, and the counter needs to be large enough that every message block can have a unique counter value. Typically, the counter is initialized to 0 and then incremented by 1 for ...

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

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

Sounds like you might be after deterministic authenticated encryption. Check out SIV mode. This mode doesn't use an IV at all (though it does generate one internally, outside of the attacker's control). Being deterministic, it leaks equality of (header, plaintext) pairs. The basic idea is to put the (header, plaintext) pair through a PRF, such as HMAC, and ...

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

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

Some remarks: a 16 byte IV is required by CBC, but you may not require a 128 bit unique value for your protocol CBC relies on an IV that is indistinguishable from random to an attacker, fixing bits in the IV is not a good idea CBC requires a padding mechanism, unless you can use ciphertext stealing Now a few calculations reveal that if you rely on the ...

3

As long as you never re-use a specific counter value with the same key, counter mode protects the privacy of the message. All counter values are equally secure. You just have to be sure never to re-use any counter value in two different messages. Zero is no different to any other counter value in this respect. However, if you ever re-use any 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

That would work and almost certainly wouldn't have any negative impact on security, but it would be cleaner just to have a string of 16 0x00 bytes at the start of a message, instead. Not only does this save you the trouble of hashing, but you stay within the standard threat model for CBC which assumes the IV is independent of the message blocks. (One can ...

2

Sending a big block of data to be then used as initialization vectors is secure (assuming it is transferred encrypted and authenticated), but kind of defeats the purpose of "keeping the message size down". The requirements for an initialization vector depend on the mode of operation, not on the underlying cipher (AES in your case). For CBC mode, the ...

2

Keeping the (initial) IV secret only adds security for the first block of your cipher text. The IV for the second block is by definition the first cipher text block, and so on. So if we would have the key but not the initial IV, we could decrypt the whole ciphertext except the first block. So it doesn't add much security, but it does add "management", as you ...

2

To answer your specific questions: From reading around I understand that ... encrypting a counter and use that as the IV is OK, is that true? For CBC mode, that is absolutely true, as long as the key that you use to encrypt the counter is secret (that is, not known to any possible adversary). Should I start in random number? Actually, that's ...

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})$, ...

2

The synthesized IV does not need to be random. AES-SIV is a deterministic authenticated encryption mode: it can be used without any nonce when it is not a concern if the attacker can tell that the same message is being transmitted (under the same key) multiple times. Privacy and authentication are still guaranteed. SIV recommends to use a nonce (more ...

2

To generate an IV securely for CBC mode, there are two obvious ways to do it (and both are cited by NIST): For each packet, select a nonce (the IPSec sequence number, padded out to 64 bits, works fine), encrypt that in ECB mode, and then use resulting ciphertext block as the IV. An equivalent way to do that is to take your 64 bit nonce, prepend that to ...

2

You should consider using an authenticated encryption (AEAD) mode. As @d-w says, and as the name implies, it will detect malicious manipulations of the cipher text stored in the DB with high probability. On top of that: you will also detect all cases where you are using the wrong key by mistake. you can authenticate any metadata associated to the credit ...

2

Probably not safely and in the way you mean. The NULL IV is completely unsafe. There are deterministic encryption schemes used for things like searchable encryption, de duplication/convergent cryptography, and key wrapping. They leak a lot of data about the underlying file you are encrypting. In general, they are not safe for generic use. Don't use them. ...

2

If you really can't use an IV (why?), then just about the best thing you can do is use something like SIV mode (RFC 5297). SIV is a "maximally misuse-resistant" authenticated encryption mode which provides the following characteristics: If every message is tagged with a unique nonce, SIV provides full IND-CCA2 security (up to the usual limits; i.e. it ...

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