Hot answers tagged initialization-vector
11
By using the file's hash as IV, you also divulge the file's hash. This allows an attacker to make an exhaustive search on the file contents. It is not difficult to imagine situations where there are only a few millions or billions of possible file contents (e.g. the file contents are an encrypted SAN or password), in which case showing the data hash is an ...
8
The requirements for an IV depend on which encryption algorithm you are using (AES is not an encryption algorithm by itself, since it can only act on 16-byte strings, but it can be used as a building block in a variety of different encryption schemes), specifically on the mode of operation.
Roughly speaking, the role of the IV is to insert some "new" ...
8
I can immediately think of four reasons:
They're both not using AES256. I see in the Obj-C document a direct statement that they are using AES256 (unless you deliberately change it), I don't see any statement in the Visual Basic document that says what key size they're using (unless that's what they mean by "Block Bits").
Different keys. AES256 takes a ...
8
If you look at the CBC diagram, you'll see that having a fixed IV is equivalent to having the first ciphertext block become the IV. If your cipher is a good pseudorandom permutation, then what you are doing does work, if and only if all timestamps are unique such that the "new IV" is unique and unpredictable.
And in fact, if you do not use the ...
7
The security of that approach is equivalent to that of normal CBC.
Your scheme with first plaintext block $IV^\prime$ is clearly identical to normal CBC with $IV=AES(IV^\prime)$. Since a block cipher is a permutation over a block, a uniformly random first plaintext block will lead to a uniformly random IV for normal CBC.
A ciphertext produced with your ...
7
There is a technique called "format preserving encryption", which could be called an "arbitrary-size block cipher". This would allow to map your set of 5-character strings onto itself. Of course, this can't really get too secure, as it has still the limitations of ECB mode: encrypting the same string with the same key always gives the same ciphertext.
Your ...
7
The most common way to transmit an initialization vector is, indeed, to prepend it immediately before the ciphertext.
When you look at the original ciphermodes the first used IVs (CBC, CFB, OFB), the IV actually does function as a 'previous ciphertext block' for the very first actual ciphertext block; placing it immediately in front of the very first ...
6
Thomas is correct; there's no attack on CFB mode if you can predict the IV; NIST is just being cautious.
With CBC, the value of the first encrypted block $C_0 = E_k( IV \oplus P_0)$, where $IV$ is the IV used for that packet, $P_0$ is the value of the first plaintext block, and $E_k$ is the evaluation of the block cipher.
If an attacker can predict the ...
6
Yes, the attacker would have a realistic chance of recovering plaintext, and preventing him from knowing the IV values does not reduce this risk.
The problem is that CTR mode encryption is effectively:
$C = P \oplus F(Key, IV)$
where $P$ is the plaintext, $C$ is the ciphertext, and $F$ is a complex function of its two inputs.
The problem with this is if ...
6
The CBC IV attack does more than that.
If I guess the plaintext corresponding to any ciphertext block I've seen before, and can predict a future IV, I can verify my guess by submitting a suitable message to be encrypted with that IV. Obviously, that could be bad if, say, I knew the plaintext to be either "yes" or "no", and only needed to find out which one ...
6
I recommend that you prepend a random 16-byte prefix. Prepending a random 16-byte prefix, before encrypting with your CFB mode, will be just as good as using a random IV. The argument is pretty similar to Using CBC with fixed IV.
If we use CFB with an all-zeros IV and a random 16-byte value prefixed to the message before encryption, as you suggested, we ...
6
Using a static IV isn't simply "poor form" — it introduces crippling weaknesses to the security of your ciphertexts. Likewise, using correctly-generated IVs (the requirements differ from mode-to-mode, but cryptographically random IVs almost always meet those requirements) isn't "better"; it's absolutely necessary.
That said, there is absolutely no ...
6
The initialization vector is XORed against the first plaintext block before encryption in CBC mode, as shown in the Wikipedia article on block cipher modes. After the first block is decrypted, you still have an intermediate value which has been XORed with the plaintext — without this, you have little hope of recovering the plaintext. However, you do not need ...
5
You obviously lose semantic security when you use deterministic encryption. This means an attacker can tell if two files are identical. publishing the unencrypted hash also leaks which file you encrypted, if the attacker knows the hash from elsewhere.
You end up with something similar to convergent encryption, which has a few issues. Check the question Is ...
5
I found a little more info on Google, so let me provide a partial answer to my own question. In particular, I found a post by David Wagner to sci.crypt in 2004, titled "IND-CPA for CFB mode", which in turn led me to a paper titled "Practical symmetric on-line encryption", published in FSE 2003 by Fouque, Martinet and Poupard.
In this paper, the authors ...
5
This is what ciphertext block chaining is about - each plaintext block is XORed ("chained") with the previous ciphertext block before encrypting (and after decrypting).
The initialization vector then takes the place of the ciphertext block before the first block (since there is none).
So, mistaking the initialization vector as a ciphertext block does ...
4
The choice or PRNG doesn't really matter much, as long as it's a decent one. I wouldn't use BBS because it's slow, and the security proof isn't too useful.
The interesting question is rather, how to seed the PRNG with sufficient entropy. You need a sufficient amount of data that an attacker can't predict. I strongly recommend not doing this yourself, but to ...
4
The short answer for the mode: use EAX.
There are several reasons why EAX is Good, but, in particular:
It includes integrity check, which is a must have (yes, really; defense against active attackers is often overlooked, and this is equally often deadly).
It needs a unique IV (a nonce) but tolerates predictable nonces.
As for OFB and CFB, see the ...
4
A key, in the context of symmetric cryptography, is something you keep secret. Anyone who knows your key (or can guess it) can decrypt any data you've encrypted with it (or forge any authentication codes you've calculated with it, etc.).
(There's also "asymmetric" or public key cryptography, where the key effectively has two parts: the private key, which ...
4
The three terms (key, IV, nonce) you mentioned, and another, the salt, basically describe random numbers and each term is used in another context. The key is used as input for a cryptographic primitive and should be kept secret.
A nonce is a random number only used once and for a short time with the intention to get replaced by or converted into something ...
4
Yes, the IV (not "IV vector" because IV = "initialization vector" :p) is public and is only used to introduce randomness in the encryption process to prevent it being fully deterministic, while still preserving entropy in the key material.
You normally send the IV along with the ciphertext (yes, it is safe if you do it right), and how it is generated ...
4
The properties that an IV must meet are strongly dependent on the mode that the IV is be used in. Some modes require unpredictability; other modes don't care about unpredictability but require uniqueness.
As for OFB mode, it's in the 'don't care about unpredictability, but require uniqueness' camp. In particular, as long as you never reuse an IV, and you ...
3
It depends on the mode of operation. With counter mode, predictable IV's are fine. Of course, a collision in file hashes would result in easy plain-text recovery.
It's probably better to fill the high order 64-bits with the number of microseconds since the unix epoc, pad the rest of the 64-bits with random numbers and the use the low order 64-bits as the ...
3
AES (as any block cipher) strifes to be indistinguishable from a random permutation, so any property like $C_1 \oplus C_2 = P_1 \oplus P_2$ would be quite bad.
This property (with $K$ as the "key stream bits") is valid for synchronous stream ciphers, including the one time pad and stream cipher modes of block ciphers (CTR, OFB, and for the first block also ...
3
Do not use a fixed IV. It can have seriously negative consequences. You don't say what mode you were going to use. This would be a pretty important piece of information for us to know.
That said, a random 128-bit IV stored in plaintext is typically what you want. The IV can be known to an attacker without breaking security.
3
Sure, that's fine, but you're really just using the first block of ciphertext as the IV.
If you choose the first plaintext block to be a running message counter (which you might as well do; it's easier than generating a random block) and your "discarded IV" to be all zeros (or vice versa) then your method is equivalent to standard CBC mode combined with the ...
3
As Seth as pointed out there are various different modes of block cipher, each have their own requirements on the IV (see this summary by Thomas Pornin).
CBC and PCBC are both modes that require the IV is unpredictable (but is stored in the clear for use in decryption). The IV is not there to add randomness / complexity to the key, but to resist a chosen ...
3
No. In the context of the Initialization Vector of a cipher operated in some mode, the most significant property of a cryptographic nonce is that it is not reused. It often matters that it is random and unpredictable (e.g. with CBC). It is immaterial that it represents a number or anything else under some particular encoding.
If an IV is chosen at random ...
3
No, it is not a good idea to use the Blum Blum Shub Generator to generate an Initialization Vector for a block cipher operated in OFB mode.
In this usage, one needs that the IV has negligible chance to match an earlier IV used with the same key.
The exact requirement is that the IV has negligible chance to match an input to the block cipher used in ...
3
"Unique" is relatively straight forward. It's something you haven't used before. Unique usually only applies to the individual party, you only need to verify that the IV is unique for your usage with the current key.
"Strong" relates to the requirements that your mode of operation has for the IV. Different modes require different constraints on the IV. ...
Only top voted, non community-wiki answers of a minimum length are eligible
