39

The IV depends on the mode of operation. For most modes (e.g. CBC), the IV must have the same length as the block. AES uses 128-bit blocks, so a 128-bit IV. Note that AES-256 uses a 256-bit key (hence the name), but still with 128-bit blocks. AES was chosen as a subset of the family of block ciphers known as Rijndael. That family includes no less than 15 ...


32

I think it's easier to split this into its component parts, and consider them as separate entities: AES and CBC. AES itself does not "basically consist of XORing together chunks of the block" - it's a much more complicated affair. Ignoring the internals of it for a moment, AES is considered secure in that without knowing the key, it's practically impossible ...


28

A blockcipher like AES is a keyed permutation. In the case of AES it takes a key and then turns a 16 byte block into another 16 byte block deterministically. To encrypt something with a block-cipher you need to use a mode of operation. Typically those modes take an IV (similar to a salt) which should be different for each message you encrypt. This ...


19

The "nonce" is better known as the Initialization Vector -- with "IV" being the universal short name for that concept. CTR mode works by encrypting the successive values of a counter (CTR stands for "CounTeR"), so the IV in CTR mode is merely the value at which the counter starts. CTR basically produces a long key-dependent pseudorandom stream, and ...


14

You need both a salt and an IV when you do... two distinct actions, one needing a salt and the other an IV. That's your case here. The salt relates to turning a password into a secret key. That's what is used in your example code: PBKDF2 is a password-based key derivation function. As anything which uses passwords, PBKDF2 needs configurable slowness (that's ...


12

Yes. This is an issue with any crypto system that does not protect integrity, such as with a signature or hmac. You see, encryption and decryption are just mathematical operations. You can always perform a mathematical operation on a blob of binary data, and will always get a result. Encrypting an decrypting operations do not error out because the data is ...


12

AES is a block cipher: it takes as input a block (16 bytes, in the case of AES) and a key (16, 24 or 32 bytes, for AES), and outputs another block (again, 16 bytes). It is a fully deterministic algorithm, fully specified, and everybody in the world ought to obtain the same output block for the same input block and key. However, you don't encrypt a block, ...


11

There are two distinct "dangers" with CBC. Remember that CBC works the following way: to encrypt a block, first XOR it with the previous encrypted block. The IV is just the "previous encrypted block" for the very first block to encrypt. The idea is that a block cipher is a deterministic permutation: with the same key and the same input block, you get the ...


10

The IV should be unique for every message encrypted, so no, if you intend to encrypt more than one secret using the key you generate from this password, you cannot reuse the salt as the IV. Reusing an IV at best leaks information about the plaintext, and at worst, can destroy your encryption scheme altogether (depending on the mode you're using) and so yes,...


9

No, because the key is secret. The "block cipher encryption" block in the diagram scrambles the data depending on the key. The XOR in the diagram does not provide the security, the encryption does. The XOR and the IV are just to make sure the same plaintext encrypts as different ciphertext for each block.


8

When encrypting the user password to store it in my database using AES-CBC, do I need to use a Key, an IV and a Salt? Whatever I need to use, how would they be used exactly? The IV is used to initialize the first 16 byte matrix of the AES-CBC encryption scheme. It is XORed with the first 16 byte of the message. This means that, if the IV is constant, the ...


8

You understand correctly. The code you found includes a common nomenclature error. i originally misread the code. Tom Leek is correct. The code isn't screwing up, but rather it's using the salt while hashing then later using an IV while encrypting. Many people conflate the terms 'salt' and 'initialization vector'. They serve the same purpose, but are ...


8

I want to clear a couple of things first: What you're seeing is the intended and correct behaviour. ECB doesn't use chaining and it applies the block cipher to the plaintext block by block separately, so there's no point to discuss IV and ECB because the two don't really work with each others. Let's start with CBC encryption. It's quite simple; take the ...


6

You must use a 128 bit IV. For CBC mode IV must match the block size, which is always 128 bits for AES. Rijndael, the winning AES candidate, is defined for 128 and 256 bit blocks, but only 128 bit blocks were standardized as AES. Some libraries support Rijndael with 256 bit blocks, but then you're no longer using AES. If you need a longer IV for some ...


6

Each encryption mode has its requirements for the IV. For GCM, the requirements are simple (see NIST SP 800-38D for details): Length should be between 1 and 261-1 bytes. It is recommended that the IV length is exactly 12 bytes (96 bits); if it is not, then GCM will need to pad and/or hash the IV first, which is not supported by all implementations, and ...


5

It is not a matter of C# -- it is intrinsic to CBC mode. In CBC, upon encryption, each block is first XORed with the previous encrypted block (with the IV for the first block), and then the XOR result is processed with the block cipher. This implies that, for decryption, you process a block with the block cipher, then XOR it with the previous encrypted block....


5

All modern encryption methods (AES, blowfish etc.) are designed to be much more secure than you seem to expect. Let us quickly look at some attacks which such ciphers are designed to be resistant against. Known plain text attack - In this case we assume the attacker has access to many plain text blocks along with corresponding cipher text blocks encrypted ...


5

You know the IV and the plaintext, as well as the raw cipher output (before the IV is applied). That is all that matters. You can ignore everything else. The only thing you can control is the ciphertext and the IV. So, how do you change the IV to predictably change the plaintext? Hint: If you have A ⊕ B = C, and you know B and C (and thus can calculate A), ...


4

The IV handling in Java is dependent on the cryptographic provider that is used. The SUN provider that comes with Oracle runtimes is rather strict; it requires the IV to be the same size as the block size for most modes of operation. This is true even for CTR mode where you might have expected that supplying a nonce - the first bytes of the IV - should be ...


4

If your IV is derived from the plaintext, so that encrypting the same plaintext twice leads to the same IV, then you lose semantic security: someone can tell whether two plaintexts are equal by comparing the ciphertexts. Other than that, for CFB, it is ok to use a predictable IV; what is critical is that the IV is not reused (or at least not reused for ...


3

The main reason you use an IV is to prevent the same plain text yielding the same encrypted text twice. With CBC you encrypt your text in blocks. Let's assume you have the following text and each line is a block: AAAAAA BBBBBB CCCCCC DDDDDD and AAAAAA CCCCCC EEEEEE FFFFFF Without using an IV, the encrypted block for AAAAAA would be the same for both ...


3

Yes, you need the same IV to initialize the decryption process. The purpose of the IV in CBC mode is to ensure that encrypting the same plaintext will result in a different ciphertext each time. By the way, are you encrypting it using AES or RSA?


3

The right way to generate an IV for CBC mode is with a cryptographically secure random generator. There are cases where a non-random IV is ok, but unless you've carefully analyzed your system to be sure that you fall into these cases, you should go with a random IV. There are very few situations where using a non-random IV would have any benefit anyway, so ...


3

A secure pseudo-random number generator (CSPRNG) is about as secure as you are going to get. Both of the references you point to are CSPRNGs so either should be sufficient for an IV. Hashing doesn't make random more random. Using two different mechanisms makes no sense and doubles the chance of making a mistake. In the case of GenerateIV, things are already ...


3

Initialization vectors aren't meant to be private. The goal of an IV isn't to strengthen the key but to make sure that no two identical (or similar) clear text will result in the same (or similar) cipher text. It works like this: AES (along with most - but not all - modern crypto algorithm) is a block cipher. It only operate on a fixed amount of data (in ...


3

The role of the IV depends a lot on the encryption system, e.g. whether it is a stream cipher or a block cipher, and, in the latter case, the mode of operation. IV means Initialization Vector: this is a generic term for the start value of any looping process. In cryptography, we use the term IV to designate a parameter that is used at the start of a ...


3

The IV has the same security requirements as the encrypted blocks. For CBC to work, you need to XOR the unencrypted data in the current block with the encrypted data from the previous block. Because there is no block before the first block (so no encrypted block can be obtained) an IV is used instead.


3

If I understood you correctly, you want to continue using the old key, which remains hard-coded, but only use it to encrypt AES keys, which are then used to encrypt and decrypt your data. This does not improve your security. The vulnerability in your old design is that the key and IV are hard-coded. If you encrypt the new key with the old key, that adds an ...


2

If I understand your question correctly, someone may know some plaintext corresponding to the cryptotext and you are worried that this may weaken your key. If so, AES is not susceptible to known-plaintext attacks. It means that knowing the plaintext corresponding to the cryptotext does not help to guess the encryption key. You just need to have a good ...


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