Tag Info

Hot answers tagged

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


6

The point of the IV is to prevent the same (key,IV) from ever being used for two different messages in practice. This is an absolute requirement for stream ciphers or block cipher modes such as CTR that are effectively stream ciphers, because re-using the same (key,IV) pair lets an eavesdropper trivially obtain the XOR of two plaintext messages, which means ...


5

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


5

Let me see if I have this right (and please correct me if I misunderstand; my conclusions depend on the details of this); you distribute images for your firmware device; these images are encrypted with a secret AES key (using AES in CBC mode); the device decrypts the image, and then runs that decrypted image. The sole check to make sure that the image ...


5

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


5

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


4

AES is a block cipher which actually only "maps" (encrypt) a 128 bit block (plainblock) to a 128 bit block (cipherblock) and vice versa. This "mapping" is key dependent. To encrypt some data you normally apply an encryption mode like CBC, CTR, GCM etc. using e.g. AES as block cipher within this mode. These modes normally require an IV or Nonce. So, not ...


4

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


3

There is not much difference and in practice the terms are often used to mean the same thing. In this context however the Nonce does not have to keep to the random properties that the IV has. As explained in the paper: A probabilistic encryption scheme $C = \varepsilon^R_K (P)$ is an IV-based encryption scheme, syntactically, but we are suggesting that, ...


3

I am using chunks of 1MB and give them a GUID as filename That is fine although unnecessary, the entire input file can be encrypted. These chunks are then first compresses using DEFLATE to minimize attacks based on known Content VERY BAD idea, since you are breaking the input file into pieces, you are now exposing the entropy of specific file ...


3

This algorithm is vulnerable to a Man in the middle. From Wikipedia: In the original description, the Diffie–Hellman exchange by itself does not provide authentication of the communicating parties and is thus vulnerable to a man-in-the-middle attack. Mallory may establish two distinct key exchanges, one with Alice and the other with Bob, effectively ...


3

In CTR, you can use any operation which has a full cycle through the space of the IV with the counter. You could use the plus operator like the example: $69dda8455c7dd4254bf353b773304eec + 1 = 69dda8455c7dd4254bf353b773304eed$ To calculate the next value, just again add 1. You could also use a increasing counter and xor it with the original IV: ...


3

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


3

Assuming perfect implementations and good block ciphers, it doesn't matter (for any of your questions). As long as the underlying block cipher is good and has a long enough block length (e.g., 128 bits, as all versions of AES have), any good mode of operation has a security theorem guaranteeing security against chosen plaintext attack for a total of about ...


2

Yes, it's secure. It is somewhat overkill, however, since you could stop replay attacks by using either: a persistent counter as IV, or a random nonce, and including a timestamp in the message. The AEAD must authenticate the IV (and GCM certainly does), so either would work without requiring any extra round-trips. You can just use the IV in the initial ...


2

Using Diffie-Hellman key agreement for generating a nonce should be safe as long as both key pairs are ephemeral, i.e. generated for each run of the key agreement protocol. Otherwise a man-in-the-middle can fool one of the parties in generating the same nonce over and over again. Ephemeral Diffie-Hellman is however overkill for generating a nonce, as the ...


2

This question is about artifacts produced by buggy debug code written in C++, and squarely off-topic; but I can't vote to close it (I tried), because there is a bounty. IMHO the problem is: char const * is not the appropriate type for a pointer to an arbitrary collection of bytes of some length, like an IV is. The thing pointed-to by a char const * is a C ...


2

It is insecure to reuse the $IV$ with AES-CBC. At the very least, if the files have a common prefix, this will be revealed as a common prefix of the ciphertexts. For AES-CBC, the only way to ensure confidentiality is to use random $IV$s. However, if you are not restricted to a particular CBC mode, the nonce-based Counter mode (CTR) might solve your problem. ...


2

The hexadecimal output of an IV matching the block size of Serpent should be 32 characters. Since you are getting 42, that is an extra 5 bytes of data. The last 5 bytes of every IV you posted is 3056E60801, which leads me to strongly believe this is an implementation issue, possibly related to reinterpret_cast. In terms of the RNG itself, it appears to be ...


2

For CFB mode: NEVER make the IV constant, it must be unique for every message. The IV does not need to be secret or impossible to predict, only unique. It can be a simple counter, for example. The IV may not be chosen by the attacker. I can not emphasis UNIQUE enough, if your IV is not unique you've basically lost all security.


2

An IV is an intial vector, which means it is an initial vector of data used when you start a chaining mode. It has no interesting properties of its own. If the IV is a nonce, that means it is a number used once (eg CTR mode). This means that (by changing the IV) we ensure that the process is never run on exactly the same input data (even if messages are ...


2

If they are not generating a new key for every encryption, then the other answers apply. If they are generating a new random key for every encryption, then there are no glaring security holes (since they are using a poor random number generator, even if they think they are generating new keys for every encryption, they might not be). That said, if they ...


1

With a 4 byte counter, it is a representation of a 32-bit unsigned integer. Since the counter increments from 0, there is no need to store it on a per message basis. This then becomes an implementation issue. A smart AES-CTR implementation would accept ANY initial counter/nonce value, and simply 0-pad it to the desired length. If we supply the cipher only ...


1

As long as the IV is not published as it usually is with CBC in the first crypt text block (I assume you wouldn't have asked in that case), the main problem I see is that encryption is deterministic, that means if you encrypt the same plain text twice you will get the same cipher text twice. As CBC works by iterating the through the plain text in blocks that ...


1

For CBC mode, the IV must be Never used twice with the same key Unpredictable So, in your example (filename$\oplus$key), if you ever encrypt two files that have the same filename with the same key, you will violate #1. Now, you may be tempted to say "but I always generate a new key for every file that I encrypt, so that example doesn't apply". Fine, ...


1

Problem statement You have a list of messages $(m_1, m_2, \dots, m_n)$, possibly with corresponding tags/descriptions $(t_1, t_2, \dots, t_n)$, that you want to store. You want to protect confidentiality of the messages (but not the tags/descriptions) against an adversary that compromises your storage. You have a single secret passphrase $pw$ at your ...


1

Dmitry Khovratovich has a very good answer, like usual. Using same IV multiple times in AES-CBC is not secure, please don't do it. I would also recommend to prefer CTR mode, but also provide you a few more useful instructions, which may aid you. If you use CBC mode and make random IVs, it is possible to make single random IV per file if you encrypt the ...


1

If you decode the resulting cipher text with a base64 decoder it says: Salted__XXXXXXXXXXX Where XXXX changes, but "Salted__" doesn't. So I guess it is a prefix added to the ciphertext to define its format.


1

Yes, as long as you obey all the total usage limits and choose the IV appropriately (see below). Whilst IV is a general term for any initialisation vector the recent trend has been to use the term 'IV' to refer to a random vector, and "nonce" (a contraction of "n-umber used once") to refer to an input vector that need not be random, but cannot be repeated. ...


1

IV (initial value or initialization vector) is a vague term that describes some kind of starting value for a mode of operation that is known to both parties, and generally sent in the clear with the encrypted data (and known to the attacker) IVs in many modes of operation have specific requirements to that mode. In some modes the requirement is that is ...



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