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

6

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

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

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

Actually, for CFB mode, the IV is the same size as the block size, 16 bytes. As for your question "does keeping the IV secret help security", the answer is "not really". CFB mode processes the message in blocks, and for each block of plaintext, combines that with the previous block of ciphertext to generate the next block of ciphertext. What the IV is ...

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

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

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

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

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

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

Don't use ECB mode. ECB mode is fundamentally unsound except in very specific use-cases. IVs have different requirements depending on the mode. In CBC mode, the requirement is "unpredictability", which is typically construed to mean "cryptographically random". CTR mode only requires that the IV be a nonce (e.g., is guaranteed to be unique). A new IV must be ...

3

If you use CBC mode and your communication protocol looks like SSL, then you may have trouble. In SSL 3.0 and TLS 1.0, the IV for each record is the last block from the previous IV; this implies that an attacker who can both inject some data of his own in the stream, and observe the outcome, may know the IV for the next record and choose his data ...

3

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

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

I am using chunks of 1MB and give them a GUID as filename That is fine although unnecessary, the entire input file can be encrypted. These chunks are then first compresses using DEFLATE to minimize attacks based on known Content VERY BAD idea, since you are breaking the input file into pieces, you are now exposing the entropy of specific file ...

2

Your assumption is flawed, you are thinking the IV used for encryption and decryption are different, and that the decrypt IV is an output from the cipher. It is only an input, and it is the same for both operations. Therefore it does not leak any information about the key or the plaintext. Is using the IV in such a way, which can keep both sides of a ...

2

I assume you mean that the CBC-mode encryption and decryption process would 'update' the "output IV" will be identical to the most recent ciphertext block. This isn't obvious from your question; for example, the diagrams you show don't show any "output IV" being generated at all. Now, for your specific questions: Does this "Output IV" holds information ...

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

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

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

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

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

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

Speaking in broad strokes, reuse of the key is fine - reuse of the IV: not fine. From wikipedia: "Properties of an IV depend on the cryptographic scheme used. A basic requirement is uniqueness, which means that no IV may be reused under the same key". You also need to decide on a mode of operation, as different modes will dictate different requirements for ...

2

No. You cannot use the same key and IV for more than one vector (with the most AES modes of operation). The only AES mode of operation which is (somewhat) resistant for IV reuse is SIV. For usual modes of operation like CBC, CTR, GCM, etc. reuse of Key+IV pair is a bad mistake. It is important to acknowledge that there are further requirements for ...

2

The hexadecimal output of an IV matching the block size of Serpent should be 32 characters. Since you are getting 42, that is an extra 5 bytes of data. The last 5 bytes of every IV you posted is 3056E60801, which leads me to strongly believe this is an implementation issue, possibly related to reinterpret_cast. In terms of the RNG itself, it appears to be ...

2

This question is about artifacts produced by buggy debug code written in C++, and squarely off-topic; but I can't vote to close it (I tried), because there is a bounty. IMHO the problem is: char const * is not the appropriate type for a pointer to an arbitrary collection of bytes of some length, like an IV is. The thing pointed-to by a char const * is a C ...

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