# Tag Info

49

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 any additional authenticated data (AAD) that needs to be send, the optional ...

37

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

34

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

32

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

28

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

22

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

20

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

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

17

The $\operatorname{SHA-224}$ is defined in the exact same manner as $\operatorname{SHA-256}$ with different initial values and the digest is obtained truncating the hash value, FIPS PUB 180-4 Page 23. The different initial value provides domain separation. With domain separation $$\operatorname{SHA-224}(m) \neq \operatorname{SHA-256}(m)|_{224}$$ where $|_{... 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 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 Even a single AES-GCM nonce reuse can be catastrophic. A single nonce reuse leaks the xor of plaintexts, so if one plaintext is known the adversary can completely decrypt the other. This is the same as for a two-time pad. In messages up to$\ell$blocks long, after a single nonce reuse the adversary can narrow the authentication key down to$\ell$... 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 You should use random IV even when unique keys are used. This prevents key-collision attack where the attacker collects number of cryptograms that have been encrypted with unique keys and brute-forces for key. Using predictable IV will reduce security of your cryptosystem by a factor of N (where N is the number of ciphertexts created). The attack recovers ... 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 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 ... 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 ... 12 With CBC mode the initialization vector is referred to as IV, because it is not nonce. There are ways to construct nonce so that it does not meet the needs of CBC mode. Random IV is one generation choice which is usually fine. Nonce can also be a counter, which is not ok here. Definitions Nonce means number used once. IV means initialization vector. CBC ... 12 The reference for this is NIST SP800-38A, especially its appendix B. Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if ... 11 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 decrypted ... 11 One example of a situation where an "IV" needs to be secret can be found in one of the original papers on the HMAC construction: Bellare, Mihir, Ran Canetti and Hugo Krawczyk. 1996. "Keying hash functions for message authentication." http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.134.8430 Quoting pages 4-5 (my boldface): The first obstacle ... 10 Reusing an IV once opens you up to someone finding the XOR of those two plaintext, seriously compromising their confidentiality. Moreover, with GCM, a single IV reuse leaks significant information about the key used for authentication; if there are even a few pairs of reused IVs (not even one IV used many times; a few IVs each of which are used twice is ... 10 This additional 32 bit nonce acts as a salt, and makes multicollision attacks$2^{32}\$ times harder. In this attack, the attacker collects a huge number of TLS sessions, each with a record encrypted with the same nonce. He then selects a random key, and generates the counter mode keystream for the key (and the fixed nonce); he then checks if that key ...

10

From a cryptographic standpoint, it doesn't matter how you transmit the IV. You can send it as a header, in the message body, as the path in the request method, or even the URG pointers in a few TCP packets. From the perspective of the encryption process itself, it doesn't care how it got the IV, no matter how silly the transmission method used, as long as ...

9

The answer by mwhs is very wrong about CBC-MAC and its use of IV!! It is perfectly fine and secure to use the same IV for CBC-MAC! In fact, Jonathan Katz and Yehuda Lindell recommend using zero vector IV when invoking CBC-MAC because it saves storage and bandwidth in practical settings! (souce: Introduction to Modern Cryptography, Second Edition) The ...

9

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

9

The use of the AES key many times is not a problem. However, there is a fundamental flaw with your solution. The server has no way of validating that it received the client's authentic public key. In particular, a man-in-the-middle can capture the client's public key, can forward its own public key to the server, and can then decrypt all traffic sent by each ...

9

In this answer I'm assuming that a key is used to encrypt more than one message. The first weakness is that CBC with fixed IV leaks if messages share a common prefix. The second weakness is that it makes a padding oracle attack much more severe. Consider a device that knows the key and decrypts a ciphertext you send to it. While it won't tell you the ...

9

That's correct. In most cases you can do what you are proposing. However be warned that by disregarding the authentication you clearly loose message authentication and bit flipping in AES-CTR encrypted stream is trivial. You can do what you are proposing if the AES-GCM IV size is of 96 bits. AES-GCM supports also longer sizes for IVs and for those cases ...

9

First, this is not safe with ChaCha because the ChaCha nonce is only 64 bits long, since ChaCha nonces are normally chosen sequentially, so there would be a nonnegligible danger of collision with a reasonable number of messages. Let's say XChaCha instead, with a 192-bit nonce, which is large enough to choose at random without danger of collision. The ...

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