53

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


44

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


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


31

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


26

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


19

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

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


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

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


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

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


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

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

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


11

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


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

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


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

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


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

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

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 $IV=K$...


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

You don't need to put the IV in the AAD (Additional Authenticated Data) as already indicated in the comments. The GCM proposal as adopted by NIST (PDF) clearly specifies this in paragraph 2.1 Inputs and Outputs: The IV is authenticated, and it is not necessary to include it in the AAD field. The NIST document SP 800-38d (PDF) does not explicitly specify it,...


9

In the general case, the security goal is to reduce the probability that the internal 128-bit counter block ever takes the same value when instantiating the GCM cipher with a given key. That is catastrophic in combination with the CTR mode. The best strategy to minimize such probability depends on how the IV is generated. Case 1: IV is deterministic, 96 ...


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


9

The question's citation is likely the reason why it was chosen different initial starting values for SHA-2 variants of the same internal block size. It is a valid objective by itself that different hash functions yield independent results, linkable only knowing their common input. It is not necessary to have a specific attack in mind to make that ...


9

No, just erasing the AES-CTR IV is not enough to reliably render the file undecryptable. To see why, consider what happens if the AES key is later compromised, and the attacker also happens to know at least one AES block (i.e. 16 bytes) of the "shredded" file's plaintext content. They can then XOR this known plaintext with the corresponding part of the ...


9

Usually. However, if you are using 128-bit AES in CTR mode (remember that GCM is essentially just CTR with authentication), then a kind of attack called a multi-target attack can become possible. This attack is realistic when an attacker has a huge amount of stored ciphertext, each with a random key. While breaking a specific key requires performing up to ...


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