Tag Info

Hot answers tagged

15

Well, the exact reason for an IV varies a bit between different modes that use IV. At a high level, what the IV does is act as a randomizer, so that each encrypted message appears to be encrypted to a random pattern, even if those messages are similar. In general, IVs disguise when you encrypt the same message twice (and more generally, when two messages ...


14

With CBC (Cipher block chaining) mode, before encryption, each block is XOR-ed with the ciphertext of the previous block, to randomize the input to the block cipher (and avoid encrypting the same block twice with the same key, as this would give the same output, and tell the attacker something about the plaintext). As the first block has no previous block, ...


14

The nCipher Advisory #13 cited in your securityfocus.com link contains the explanation of the vulnerability (in the section "Cryptographic details"). The CBC-MAC algorithm works similar to the CBC encryption algorithm, but only outputting the final block (or a part of this). Each block of the plain text is XOR-ed with the previous ciphertext and then ...


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


13

Well, to start off with, IVs have different security properties than keys. With keys (as you are well aware), you need to hide them from anyone in the middle; if someone did learn your keys, then he could read all your traffic. IVs are not like this; instead, we don't mind if someone in the middle learns what the IV is; as long as he doesn't know the key, ...


11

There is a technique called "format preserving encryption", which could be called an "arbitrary-size block cipher". This would allow to map your set of 5-character strings onto itself. Of course, this can't really get too secure, as it has still the limitations of ECB mode: encrypting the same string with the same key always gives the same ciphertext. Your ...


11

Many cryptographic algorithms are expressed as iterative algorithms. E.g., when encrypting a message with a block cipher in CBC mode, each message "block" is first XORed with the previous encrypted block, and the result of the XOR is then encrypted. The first block has no "previous block" hence we must supply a conventional alternate "zero-th block" which we ...


11

By using the file's hash as IV, you also divulge the file's hash. This allows an attacker to make an exhaustive search on the file contents. It is not difficult to imagine situations where there are only a few millions or billions of possible file contents (e.g. the file contents are an encrypted SAN or password), in which case showing the data hash is an ...


11

The security of that approach is equivalent to that of normal CBC. Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC. A ciphertext produced with your ...


10

Depending on the mode of operation, transmitting the IV encrypted (with the same key as used for the rest of the process) can actually weaken security a lot. For example, in the CFB and OFB modes, the IV is encrypted and the result XORed with the first block of the plaintext to produce the first block of ciphertext. Thus, an adversary who knows the ...


10

The requirements for an IV depend on which encryption algorithm you are using (AES is not an encryption algorithm by itself, since it can only act on 16-byte strings, but it can be used as a building block in a variety of different encryption schemes), specifically on the mode of operation. Roughly speaking, the role of the IV is to insert some "new" ...


9

It depends on the chaining mode. With recent modes like EAX and GCM, the IV just needs to be non-repeating, so a timestamp is OK (as long as you take care never to issue two messages with the same timestamp: this can be a problem if you emit two messages in, say, the same millisecond, or if the sender clock is somehow reset through manual action or NTP; ...


9

Yes, the attacker would have a realistic chance of recovering plaintext, and preventing him from knowing the IV values does not reduce this risk. The problem is that CTR mode encryption is effectively: $C = P \oplus F(Key, IV)$ where $P$ is the plaintext, $C$ is the ciphertext, and $F$ is a complex function of its two inputs. The problem with this is if ...


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


8

The CBC IV attack does more than that. If I guess the plaintext corresponding to any ciphertext block I've seen before, and can predict a future IV, I can verify my guess by submitting a suitable message to be encrypted with that IV. Obviously, that could be bad if, say, I knew the plaintext to be either "yes" or "no", and only needed to find out which one ...


8

You say that a random IV "would also be unique", but really that is the crux of the problem. The problem with counter mode is that it is secure unless the same counter is used twice; if it is, it is likely that an attacker will be able to recover both plaintext messages. This contrasts with CBC mode, which if you repeat an IV, it has the relatively benign ...


8

A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.). (There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which ...


8

I can immediately think of four reasons: They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits"). Different keys. AES256 takes a ...


8

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

Cryptographically speaking, AesManaged uses AES in CBC mode. To ensure this operates securely, you need to choose the IV randomly, i.e. it should not be possible to predict the IV between iterations. This question has a discussion of non-random IVs: Using a Non-Random IV with modes other than CBC and this SO question: Why is using a Non-Random IV with CBC ...


7

No, they do not gain an advantage; part of the definition of IV is "information that is used to encrypt data which can be sent in the clear". In fact, it is actually rather common to send the IV along with the encrypted message. TLS version 1.1, IPsec, IKEv2 are all protocols that do that. In CBC mode (which you didn't specifically ask about, but it is ...


7

Thomas is correct; there's no attack on CFB mode if you can predict the IV; NIST is just being cautious. With CBC, the value of the first encrypted block $C_0 = E_k( IV \oplus P_0)$, where $IV$ is the IV used for that packet, $P_0$ is the value of the first plaintext block, and $E_k$ is the evaluation of the block cipher. If an attacker can predict the ...


7

I found a little more info on Google, so let me provide a partial answer to my own question. In particular, I found a post by David Wagner to sci.crypt in 2004, titled "IND-CPA for CFB mode", which in turn led me to a paper titled "Practical symmetric on-line encryption", published in FSE 2003 by Fouque, Martinet and Poupard. In this paper, the authors ...


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


7

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


7

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


6

For block ciphers, it depends on which mode of operation you're using — nobody uses just a plain block cipher for anything, at least not unless all their messages are shorter than a single cipher block (typically 8 or 16 bytes). ECB mode, which just amounts to chopping the message up into blocks and feeding each block through the cipher, does not use ...


6

I recommend that you prepend a random 16-byte prefix. Prepending a random 16-byte prefix, before encrypting with your CFB mode, will be just as good as using a random IV. The argument is pretty similar to Using CBC with fixed IV. If we use CFB with an all-zeros IV and a random 16-byte value prefixed to the message before encryption, as you suggested, we ...


6

CFB with a fixed IV? Yikes! That is completely insecure: for the first 16 bytes of plaintext, it is even worse than ECB mode, and that's saying something. Please go enlighten whoever thought it was a good idea to expose this as the only mode of encipherment available (or even one among multiple options). Let me elaborate. It sounds like the baseline is ...


6

CBC mode encrypts as follows: $$ C_0 = E_K(IV\oplus P_0);\\ C_i = E_K(C_{i-1}\oplus P_i), $$ where $P_i$ are plaintext blocks and $C_i$ are ciphertext blocks. Traditionally, IV must be random and is published alongside the ciphertext to enable decryption. If it is also published in your case, then this reveals the key and is trivially insecure. If the ...



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