Tag Info

Hot answers tagged

8

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


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


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

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

This is not a mathematical proof. A notable place it fails to be a proof is here: Pay attention to which cipher text I use, look up to match the message with the cipher-number below. $$ cipher1⊕cipher3=character1⊕character3⊕IV1⊕IV2$$ (Note that the cipher BOTH use the SAME KEY, but they remain secure because of the two different IV) This line is ...


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


4

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


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

There are many reasons why the IV could be expected as an input parameter: it could be to let the user use his/her own random number generator, possibly because the device has none (as G_G has already stipulated) it could be to allow for creating larger ciphertext (as ArtjomB has already mentioned) by using the IV to contain the last vector it could be to ...


3

It offers more flexibility in using that API. Having a separate IV parameter enables bigger plaintexts than would not be possible in a single invocation, because of for example memory restrictions. I assume CBC is used. You generate the IV and invoke the encryption on the first part of the big plaintext with the generated IV. For every other part of the ...


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


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

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

Simply put: No. First recall that this is a mis-use of the term "One Time Pad" So lets call it a vigenere cipher instead. You can determine this is insecure with a simple algebraic combination: $ \text{attack} = cipher_1 + cipher_2 + cipher_3 + cipher_4 \\ \text{Simplify: } \\ \text{attack} = character_1 + key_1 + IV_1 + character_2 + key_2 + IV_1 + ...


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

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


2

Yes, it is correct. Just follow the bits in the decryption pictures on the Wikipedia page about modes of operation. Modes of operation don't have to have a meaning compared to other modes of operation. I don't see CFB or OFB used too much anymore. OFB with partial feedback has been shown to be less secure, so that shouldn't be used anymore. Currently the ...


2

Aren't $IV_1$ and $IV_2$ public in TLS 1.2 as well? $IV_1$ certainly is (as that's just the ciphertext block in front of the block we're attacking); however the IV that the TLS 1.2 sender will use for the next message ($IV_2$) is not. In fact, the sender might not know it yet, as it might not have not picked it yet. But doesn't this mean that BEAST ...


2

AES-CTR is very appropriate. Since a credit card number is 16 characters long, it can be encrypted using a single 128-bit block without any encoding. You will only need 1 block, and hence not require a block counter, just the nonce. Depending on the amount of card numbers being stored, you would only need to store a portion of the full nonce. A 32-bit ...


2

You can use your HardwareID as basis for the encryption key. If the ID provides enough entropy it'll work. However, if anyone can somehow obtain the ID (which might be quite easy to do) one can decrypt the file. For CFB-Mode the IV must indeed be unpredictable (but need not be secret), so random is just fine, but DO NOT REUSE AN IV. Encryption large ...


1

For CBC mode, the IV can be generated in any manner where it would be unpredictable to an attacker from one message to the next. In practice that means a random number generator of some kind. Since the block size is 128-bits, the probability of IV repeat before the key expiration is negligible. The CBC IV is visible to an attacker viewing your ciphertext; as ...


1

It would really help to see the encryption and decryption code, as used by your program. The Handling of the IV does not seem right. The IV has the size of the block of the cipher used in conjunction with CBC. Thus it should probably be 16 bytes in length. Additionally you have to use the RAW bytes for CBC and not its Base64 representation. In order to ...


1

For CBC encryption, you would store the initialization vector as the beginning of the ciphertext, regardless of whether you read in an IV or generated it yourself. The CBC decryption algorithm would do what you described at the end of your post. Your implementation should also offer access to the block cipher itself, without any mode of operation.


1

It just leaks information about the blocks with the same IV. Specifically, if the two messages encrypted with the same IV started with blocks $M_0$ and $M'_0$, then the attacker learns the value $M_0 \oplus M'_0$ (and if those where the same, then the attacker also learns the corresponding xor with the second block, etc) However, the attacker learns ...


1

First, you have to know what padding you are using. In the padding, you will find the padding length. Second, you should set the padding type in the library. Third, removing and validating and using padding is tricky and can lead to some padding oracle attacks. In essential, the attacker modifies a block, which is likely to result in wrong padding and a ...


1

I cannot prove that your scheme is secure, but as far as I know, a non-cryptographic hash function would work fine as there is an infinite number of inputs to any given hash, making it impossible to bruteforce all but the shortest messages (which would be an issue for short messages, you may want to append some sort of 128-bit padding). However, that said, ...


1

TLDR: Don't invent your own protocol, use an existing one. Reusing an initialization vector with the same key is always a problem, even if the attacker is read-only. For CBC, you can see whether a beginning part of one message is the same as the beginning part of a different message (and you get to know the length of the common prefix, on block-level). ...



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