3

I'm writing a Java program that encrypts strings with AES-CBC encryption. (Eventually I'm going to add steganography functions too).

As you are well aware, CBC needs an IV in order to encrypt the first block since there are no previous blocks to inherit from.

I have done some research on IVs, and from what I can find:

  • The IV should be random
  • The IV should change from message to message

Currently, for ease of testing/debugging purposes, I'm using a fixed IV.

However, now that I have most of the bugs worked out in my program, I'm looking to improve the security by removing that fixed IV.


What I'd like to know is: Is it secure use a second key for the IV?

For example, my program currently prompts the user for a key of the appropriate length for the encryption process.

What If I prompted the user for either:

A) 2 keys (of the same length; one for IV and the other for the actual encryption)

B) 1 key twice as long (splitting it into two parts; the first for the IV & the second for the actual key)?

Would that be secure?

  • 1
    How about generating a random IV and storing it with the data like everything else does? – Ry- Jun 23 '16 at 0:55
6

The IV is a random non-secret value. Its sole purpose is to prevent two similar blocks from yielding the same ciphertext as it could give information away about the structure of the plain text.

In general you just generate the IV randomly and concatenate it to the ciphertext. The IV must be of the same length as the block for AES-CBC, which is 128 bits. You can just concatenate it the to the ciphertext (e.g. IV+ciphertext). You know the first 16 bytes will be the IV.

EDIT

If it's common to put the IV directly in front of the ciphertext, isn't it a security risk to do it like that?

The sole purpose of the IV is to randomize the ciphertext to prevent two similar plaintext blocks yielding the same ciphertext. This is especially important for files with a fixed structure. Have a look here on why this is important.

In CBC you XOR the ciphertext version of the previous block with the current block before applying AES on it. The reason you have an IV is because the first block doesn't have a block-1 to be XORed with. Hence you just generate 16 random bytes. It's similar to salting passwords.

What makes putting a random IV in front of the ciphertext more secure than choosing a static IV?

A static IV would defeat the purpose as you would still have all similar first blocks yielding the same ciphertext.

In both cases the IV would be plainly visible. Doesn't having the IV allow you to quickly brute-force the first block?

The IV is not part of AES, it's part of a mode of operation which AES supports.

I see you are quite confused about these concepts. If you want a good read and introduction you should have a look at Keith Martin's "Everyday Cryptography". It's a good book that explains everything step by step. Cryptography is complex, hard and mistakes can have devastating consequences. Be careful when implementing existing ciphers, if it is for use in application you are better off using established, vetted libraries.

  • Thanks for the answer. So I guess I'm not understanding why the IV doesn't need to be secret. If it's common to put the IV directly in front of the ciphertext, isn't it a security risk to do it like that? What makes putting a random IV in front of the ciphertext more secure than choosing a static IV? In both cases the IV would be plainly visible. Doesn't having the IV allow you to quickly brute-force the first block? – Android Dev Jun 23 '16 at 2:48
  • Have a look at my answer – Lucas Kauffman Jun 23 '16 at 3:15
  • I know comments aren't supposed to be solely for saying thanks, but thank you immensely! – Android Dev Jun 23 '16 at 11:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.