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


5

The entire block consists of a $n$ bit nonce and a $128-n$ bit counter. Typically $n=64$. The nonce needs to be large enough so that every message under the key can have a unique one, and the counter needs to be large enough that every message block can have a unique counter value. Typically, the counter is initialized to 0 and then incremented by 1 for ...


5

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


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

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


4

For all standard modes, AES isn't secure at all if you reveal the key; even if you keep the IV hidden. Exactly how this works out varies between modes; for CBC mode, the attacker will be able to decrypt the entire text except for the first block (well, last block because of your reversing the file), even if you didn't give him an IV. The same goes for CFB ...


4

Well, there is no really good way; the encryption of the plaintext is $E_k( Plaintext \oplus IV)$ (followed by 16 bytes which are a deterministic function of the first ciphertext block). The AES function $E_k$ is designed to be totally unpredictable if you don't know the key, there's nothing to leverage there. The only thing that allows you to gain any ...


4

As long as you never re-use a specific counter value with the same key, counter mode protects the privacy of the message. All counter values are equally secure. You just have to be sure never to re-use any counter value in two different messages. Zero is no different to any other counter value in this respect. However, if you ever re-use any counter ...


4

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


3

Don't use ECB mode. ECB mode is fundamentally unsound except in very specific use-cases. IVs have different requirements depending on the mode. In CBC mode, the requirement is "unpredictability", which is typically construed to mean "cryptographically random". CTR mode only requires that the IV be a nonce (e.g., is guaranteed to be unique). A new IV must be ...


3

If you use CBC mode and your communication protocol looks like SSL, then you may have trouble. In SSL 3.0 and TLS 1.0, the IV for each record is the last block from the previous IV; this implies that an attacker who can both inject some data of his own in the stream, and observe the outcome, may know the IV for the next record and choose his data ...


3

Some remarks: a 16 byte IV is required by CBC, but you may not require a 128 bit unique value for your protocol CBC relies on an IV that is indistinguishable from random to an attacker, fixing bits in the IV is not a good idea CBC requires a padding mechanism, unless you can use ciphertext stealing Now a few calculations reveal that if you rely on the ...


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

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


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


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

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


2

Your assumption is flawed, you are thinking the IV used for encryption and decryption are different, and that the decrypt IV is an output from the cipher. It is only an input, and it is the same for both operations. Therefore it does not leak any information about the key or the plaintext. Is using the IV in such a way, which can keep both sides of a ...


2

I assume you mean that the CBC-mode encryption and decryption process would 'update' the "output IV" will be identical to the most recent ciphertext block. This isn't obvious from your question; for example, the diagrams you show don't show any "output IV" being generated at all. Now, for your specific questions: Does this "Output IV" holds information ...


2

To generate an IV securely for CBC mode, there are two obvious ways to do it (and both are cited by NIST): For each packet, select a nonce (the IPSec sequence number, padded out to 64 bits, works fine), encrypt that in ECB mode, and then use resulting ciphertext block as the IV. An equivalent way to do that is to take your 64 bit nonce, prepend that to ...


2

You should consider using an authenticated encryption (AEAD) mode. As @d-w says, and as the name implies, it will detect malicious manipulations of the cipher text stored in the DB with high probability. On top of that: you will also detect all cases where you are using the wrong key by mistake. you can authenticate any metadata associated to the credit ...


2

If you really can't use an IV (why?), then just about the best thing you can do is use something like SIV mode (RFC 5297). SIV is a "maximally misuse-resistant" authenticated encryption mode which provides the following characteristics: If every message is tagged with a unique nonce, SIV provides full IND-CCA2 security (up to the usual limits; i.e. it ...


2

Probably not safely and in the way you mean. The NULL IV is completely unsafe. There are deterministic encryption schemes used for things like searchable encryption, de duplication/convergent cryptography, and key wrapping. They leak a lot of data about the underlying file you are encrypting. In general, they are not safe for generic use. Don't use them. ...


2

No. You cannot use the same key and IV for more than one vector (with the most AES modes of operation). The only AES mode of operation which is (somewhat) resistant for IV reuse is SIV. For usual modes of operation like CBC, CTR, GCM, etc. reuse of Key+IV pair is a bad mistake. It is important to acknowledge that there are further requirements for ...


2

Speaking in broad strokes, reuse of the key is fine - reuse of the IV: not fine. From wikipedia: "Properties of an IV depend on the cryptographic scheme used. A basic requirement is uniqueness, which means that no IV may be reused under the same key". You also need to decide on a mode of operation, as different modes will dictate different requirements for ...


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

If the last 16 bytes of the ciphertext are the padding, then you actually have the simple ECB (Electronic CodeBook) mode. ECB is secure as long as all your plaintexts are 1 block long and never repeat.


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

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

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



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