2

I need to encrypt blocks of 16KiB with AES256. I have only one requirement to satisfy - If one day a hacker gets the data without the keys, he will not be able to decipher the data.

According to the design:

  1. Each block will have a different random key
  2. Blocks are differ from each other

Due to a space problem, i'm planning to use no salt and no IV.

  1. Given 1 + 2, is it still safe to waive the salt and the IV?
  2. Which mode should i use?

Thanks

yahavi
  • 125
  • 2
  • 7

2 Answers2

5

There are two blocks to consider here. The 16KiB blocks you mention you have to encrypt and the blocks as encrypted by the AES block cipher. Let's call your blocks fragments.

ECB is secure for blocks that are not related to each other in any way. Your fragments, however unique, may still contain blocks that are not unique. If this is the case then ECB will leak information about identical blocks. CBC will overcome this, especially if each block has it's own key.

So:

Given 1 + 2, is it still safe to waive the salt and the IV?

Yes, but not for ECB; ECB is almost never a good idea.

Which mode should i use?

CBC or any other mode that is secure for protecting data at rest.

You need an authenticated cipher or MAC if you also require integrity and authenticity. These are basically always required within transport protocols.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
4

Here is the deal, yes, if you encrypt with ECB and use a new key for every block, you don't fall prey to the common ECB mode weaknesses, but that also means you have to store all those keys. That doubles your storage requirement. I can't think of any good reason to do this. Why would you increase your storage requirements so much just to avoid having to use an IV? This seems entirely inconsistent with your statement that "Due to a space problem, I'm planning to use no salt and no IV." Using a new random key for every block only makes the space problem worse (though maybe in a different place).

One of the most common modes of operation is CBC mode. With this mode, you only have one key and one IV. The blocks are then chained together, mitigating the typical weaknesses of ECB mode. Thus, for the additional storage overhead of one single block, you can get the same security as your ECB+random key for every block idea. This is a significant win for storage and is also a win for efficiency as you can compute the key schedule once (with AES).

Now, that said, these days, it is important to consider adding integrity protection to your ciphertext. Both your method and using CBC suffer from a common flaw, you cannot detect (in a cryptographically secure manner) whether or not an attacker has modified the ciphertext. To gain this protection, we use authenticated encryption.

Community
  • 1
mikeazo
  • 39,117
  • 9
  • 118
  • 183