132

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


35

I'll answer in order: Output size = input size That's correct, GCM uses CTR internally. It encrypts a counter value for each block, but it only uses as many bits as required from the last block. CTR turns the block cipher into a stream cipher. Note that this doesn't include the optional additional authenticated data (AAD), the optional IV nor the required ...


33

Caveat: as very rightly pointed in that other answer, using a fixed/no IV does make some attacks less difficult. I wish the following answer would have been less affirmative. I have accordingly made adjustments in italic. There's no imperious need for an IV when unique keys are used. Given that a 256-bit key cipher is used, what's proposed is safe. When ...


30

Normally, in a properly designed cryptographic system, everything that must remain secret is either actual data (and the system exactly aims at preserving that confidentiality) or a key. Everything else ought to be public or at least publishable with no ill effect, as per Kerckhoffs' principle. Now it so happens that a number of cryptographic systems are ...


27

Lets see if I can clarify things for you. For one, the IV is not specifically related to AES at all. AES is a keyed invertible transform from a 128 bit value to a 128 bit value; that's all it can do. Now, if you just happen to have a 128 bit value that you want 'encrypted' into a 128 bit ciphertext, well, you can just use AES as is. However, we typically ...


26

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


25

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


24

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


23

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


22

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


21

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


21

The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret. A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something ...


18

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


18

If your IV is predictable this is as (in)secure as assuming that you have a zero vector IV. And a zero vector IV allows you to perform a so-called Adaptive Chosen Plaintext Attack (ACPA). Why? Assume that you have a encryption mechanism that works in CBC mode. This means, that on the first iteration the $IV$ is XORed with your input message (which is ...


18

From the proposal of GCM (rewritten if statement): if $\operatorname{len}(IV) = 96$ then $Y_0 = IV || 0^{31}1$ else $Y_0 = \operatorname{GHASH}(H, \{\}, IV)$. So there are additional calculations for IV's other than 96 bits. This is why the original proposal has this recommendation: 96-bit IV values can be processed more efficiently, so that [ed: ...


17

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


17

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


17

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


17

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


15

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


14

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


14

As the name suggests, CTR mode works by encrypting a counter (that gets incremented with each 16-byte block) to generate a stream of random bits. That bit stream is then XOR'ed with the plaintext to create the ciphertext. The IV provides the initial value for the counter. CTR mode is secure as long as the probability of a counter value repeating is ...


14

It actually leaks information. You are sending: Encrypted IV: $AES(k,IV)$ First ciphertext block of CBC: $AES(k, M_1 \oplus IV)$ Eavesdropper can observe whether the two blocks are equal, which happens iff $M_1$ is all zeroes.


13

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


13

Do not use a fixed IV. It can have seriously negative consequences. This is especially true for CBC mode. That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.


13

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


13

Yes, it is. PBKDF2 derives a DK, a "derived key", which is indistinguishable from random. This is mainly because function within PBKDF2 is HMAC, and HMAC is a PRF. Let's see the definition from Wikipedia: In cryptography, a pseudorandom function family, abbreviated PRF, is a collection of efficiently-computable functions which emulate a random oracle in ...


13

You shouldn't think of it as ‘using an IV with AES’. In fact, unless you are a cryptographer, you should forget that ‘AES’ itself exists as a thing: it is a pseudorandom permutation family $\operatorname{AES}_k\colon \{0,1\}^{128} \to \{0,1\}^{128}$, which is a technical jargon term that is practically meaningless to any application developer. Instead, you ...


12

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


12

It sounds like you're using a password-based key derivation function that accepts an optional salt input to convert a passphrase into an encryption key, which you then use to encrypt messages with a block cipher mode (or possibly some other type of stream cipher) that takes an IV or a nonce, and you want to know whether it's necessary to provide a salt to ...


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