8

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


6

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


5

Am I missing anything? No, you are not; if you use a key only once, that is, to encrypt a single message, and never use it to encrypt anything else, then it doesn't matter what nonce you use. An implicit 'all-00' nonce is as good as any. BTW: AES-GCM also uses the nonce as a part of the transform that generates the integrity tag; however, that addition ...


4

But, for the purpose of optimization, I was thinking to delete only its IV and Tag, thus hoping to make decryption of that segment's data computationally infeasible. Neither work. The IV might seem to work (as doing a brute force search over a space of size $2^{96}$ might appear to be daunting), however the attacker has another potential approach. If an ...


4

Yes, the initialization vector is transmitted in the clear as first part of the ESP payload data (see RFC 4303, section 2, and the RFCs that define the use of specific algorithm with ESP, e.g. RFC 3602, section 3 for AES-CBC, or RFC 4106, section 3 for AES-GCM). The security of the encryption and integrity protection does not depend on the IV being kept ...


4

This usage is very insecure as it can leak the AES KEY (If decryption is allowed). Consider this case where the server prints the decrypted text. The attacker can modify the $C_i$ to recover the $IV$, and in this case yields the secret $K$. Assume three blocks of plaintext is encrypted to get \begin{align} C_0 &= E_K(IV\oplus P_0); \\ C_1 &= E_K(C_0\...


4

The security contract for AES-CBC is that the initialization vector must be uniform random and unpredictable in advance—mere uniqueness is not enough (nor even necessary). It is safe to choose the IV as a pseudorandom function of a unique nonce, or even as a pseudorandom permutation of a unique nonce, which the sender and receiver can agree on—e.g., they ...


4

It is simple. Just decrypt first 8 bytes encrypted buffer(1 block) in ECB mode (You only need encrypted buffer and key to do so) and then xor the result with the input buffer. Result will be IV. In decryption of CBC, IV just affect first block. That's why only first block is incorrect in your case.


4

can I determine the IV In CBC block cipher mode of operation, not restricted for AES, the decryption of the first block is $$P_1=Dec(K,C_1)\oplus \text{IV}$$ Where $P_1$ is the first plaintext and $C_1$ its encryption of $P_1$ with the key $K$ under the CBC mode of operation. Therefore $$\text{IV} = P_1 \oplus Dec(K,C_1)$$ even if I don't know the ...


3

The term for the parameter to AES-GCM that must be unique from message to message for any single key is sometimes called ‘nonce’ and sometimes called ‘IV’. The security contract for AES-GCM requires that only that this never be repeated, and so it is appropriate to call it a nonce, meaning number used once. In contrast, for, e.g., AES-CBC, there is a ...


3

In AES-CTR, the ‘IV’ and ‘counter’ are different concepts. To encrypt a message, you specify a nonce, like a message sequence number—sometimes called an ‘IV’. The nonce is usually 64 or 96 bits, but it could be anywhere from 0 to 128 bits long. For security, you must never reuse a nonce with a key. The length of the nonce for the particular AES-CTR ...


3

This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation. ...


3

Assuming that the nonce values are unique and generated according to some fixed public counter sequence that is not under the attacker's control, is the encryption scheme described above (i.e. pad the nonce to a full cipher block, prepend it to the plaintext, and encrypt the result using CBC mode with an all-zero IV) actually IND-CPA secure? Yes, nonce-...


3

Question: is it safe to use the DERIVED key, where the ORIGINAL key is the same, but the salt is different every time? No, but the reason is a little tricky. First, forget AES-CBC—you should use an authenticated cipher like AES-GCM (if you must use AES) or NaCl crypto_secretbox_xsalsa20poly1305, and focus on the security contract. AES-CBC is hard to use ...


3

DES is an (8-byte) 64-block cipher with 56-bit active key and 8-bit parity bit (which makes total 64), and the parity bits generally discarded, i.e. not checked. When using a block cipher mode of operation you need an IV (or Nonce), except the insecure ECB mode. The IV size is determined by the mode of operation and in archaic modes (CBC, CTR, OFC, CFB) it ...


3

The IV is part of the block cipher mode of operation, not of the block cipher itself. The block cipher simply doesn't have any input for an IV, it just takes an input block and produces an output block using a key. So you cannot implement an IV for DES itself. The block size is however usually of influence to the mode of operation. Even then, the IV may ...


3

Actually, contrary to what kelalaka says, the length (and existence) of the IV depends on the exact mode of operation; some modes of operation take an IV whose length differs from the block size, and there are modes of operation (other than ECB) which don't take an IV at all. Now, with DES, by far the most common mode of operation is CBC, which does take a ...


2

For key $k_0$, nonce $n$ (‘initialization vector’), and message $m = m_0 \mathbin\| m_1 \mathbin\| \cdots \mathbin\| m_{\ell - 1}$, the AES-CTR ciphertext is $c = c_0 \mathbin\| c_1 \mathbin\| \cdots \mathbin\| c_{\ell - 1}$ where $$c_i = m_i \oplus \operatorname{AES}_{k_0}(n \mathbin\| i),$$ where $n \mathbin\| i$ is some unique encoding of $n$ and $i$ as a ...


2

What you are describing is related to the synthetic initialization vector or SIV family of authenticated ciphers, where the cipher is a deterministic function of a key and a message without a separate initialization vector or nonce. Such ciphers cannot conceal repeated messages, but that is the only inherent flaw. Some ciphers also admit specifying an IV ...


2

You can use a null IV for all files ONLY if each file will be encrypted with a unique key. If you want to reuse the key, it's safer use a random IV for each file. The issue is reusing the IV with the same key, when you do that, you reveal which files have the same first bytes. When you use a different key for each file, you don't have this problem.


2

The IV for GCM mode, in this case the thing we call the Nonce, is different from the IV used for the CTR mode inside of GCM. Additionally as per the wording of your question, AES256 has a 256-bit key and a 128-bit block, not a 256-bit block, and encrypts plaintext in 128-bit increments. For GCM, you MUST use a unique Nonce for every message. Inside GCM, ...


2

In short; salt is used for Key derivation function together with the password. IV is used for CBC which must be unpredictable. In details; The document is sparse for the details. One can guess that is is for key derivation from the supplied password and salt instead of a key. So the initial guess was it is used for key derivation from the password. When we ...


2

No, when an IV is repeated as in $C_1 = \textsf{GCM}(K,IV,M_1)$ and $C_2 = \textsf{GCM}(K,IV,M_2)$, the resulting ciphertexts leak $M_1 \oplus M_2$ to an eavesdropper. This is because GCM is based on CTR mode which has this property. Authenticity also completely breaks in this scenario, although it's not a one-liner explanation. An attacker who sees $M_1, ...


2

No, because in order to decrypt it you must pass along the SHA-256 hash too, and now you have leaked a public function of the original message, which an adversary can use to efficiently test a guess offline about what the original message was. If you want a deterministic authenticated cipher, you might consider an existing construction like SIV that has ...


2

Yes, the IV is the same in both encryption and decryption for all modes that use an IV. And yes, the decrypter must have access to the IV to decrypt the ciphertext. The IV is not a secret. The only caveat is that for CBC mode the IV must be unpredictable to an attacker whose data is being encrypted by another party. Once the attacker has presented the ...


2

The requirements differ per mode of operation. AES itself is a block cipher, and as block cipher, it doesn't take an IV at all. Tweakable block ciphers may take a tweak, which may have some overlap with an IV, but AES isn't tweakable by itself. CBC requires an unpredictable IV (to the adversary). One of the common ways is indeed to generate a 16 byte (one ...


2

For key derivation use PBKDF2, Bcrypt, Scrypt, or better use Argon2id. Argon was the winner of the Password Hashing Competition question: is it safe to use the DERIVED key , where the ORIGINAL key is the same, but the salt is different every time? If you use a different randomly generated salt, you will be fine. You can also append a counter to the ...


2

If the counter mode started at $\text{Nonce}\mathbin\|0^{32}$ instead of at $\text{Nonce}\mathbin\|0^{31}\mathbin\|1$ then one could submit an encryption query for $(0^{96},0^{128})$, i.e. the 128-bit all-zero plaintext along with the all-zero nonce. The first block of the ciphertext would then be computed as $E_K(0^{128})\oplus 0^{128}=E_K(0^{128})$ which ...


1

I want to know if the following would also be equally secure Yes, both schemes are equally secure. Also for what you are trying to achieve you really shouldn't puzzle things together yourself but rather use pre-made modes like AES-GCM, AES-EAX or ChaCha20-Poly1305. In fact, we can prove the above claimed security equivalence. Because Encrypt-then-MACis ...


1

However, if your message is exactly 128 bits long, do you only perform the XOR with the IV and the encryption with the key once? Or is there a way to split up a 128 bit message so that you can perform the cipher block chaining method as intended. This is a non-starter, as there is nothing wrong with performing a single block encrypt in CBC mode. For 128 ...


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