# Tag Info

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

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

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

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 + ... 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 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 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 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 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 ... 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 ... 1 Indeed both have the aim to prevent same messages "encrypting" to the same plaintext. The difference is the context. People speak about using IVs if they want to use them in blockcipher modes, like CTR or CBC. People use the word "salt" if they want to refer to something that is stored in public but must be somewhat random and large. Usually this applies ... 1 Well, your requirements sound pretty much like standard disk encryption ones. Assuming you can assign IDs (0,1,2...) to each 4kiB sector implicitely.In this case you could simply use XTS-mode of encryption using AES. You'd then iterate through the 4kiB block using the inner counter and iterate through all sectors using the outer counter. This should give ... 1 Yes. They're called Format-Preserving Encryption schemes, and this is the best known construction of that. 1 During CBC mode decryption, each ciphertext block is first decrypted with the block cipher, and then the first decrypted block is XORed with the IV, while later blocks are XORed with the previous ciphertext block: Thus, the first block of plaintext is computed as: $$P_1 = IV \oplus D_K(C_1).$$ Equivalently, we may solve this equation for$IV$to obtain: ... 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). ... 1 The short answer is that cracking the key of (black-box) AES is impractically difficult. If you introduce sidechannel leakage then it's a very different story, but that's probably not what you're interested in. Let us ignore the mode of operation completely, and assume that the attacker is allowed to directly query both$\mathcal{E}_k(\cdot)\$ and ...

1

I assume your protocol is message oriented. You needn't repeat the IV, but need to supply a new one for every message. This can be either: a random string from a CSPRNG, a concatenation of a random string (sent once per session, if you're traffic-savvy) and a message counter (can be omitted from the packet, too), or a member of any other unique sequence ...

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