2
$\begingroup$

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

$\endgroup$
  • 1
    $\begingroup$ So you can store all those random keys, but can't store a single IV? That just seems strange. $\endgroup$ – mikeazo Sep 11 '16 at 15:22
  • $\begingroup$ What's the meaning of a single IV? I can store it if you think its better. Currently, i'm using ECB mode that does not request for IV. $\endgroup$ – yahavi Sep 11 '16 at 17:28
  • $\begingroup$ If each block of data is encrypted with a different random key, I think there's no need to use an IV or salt (assuming the keys are properly generated). An IV is useful if one key is used to encrypt multiple pieces of data $\endgroup$ – Hanno Sep 12 '16 at 6:21
  • $\begingroup$ If each block is encrypted with a different random key, you might as well use one random key and use that now-unused storage to handle IVs. $\endgroup$ – Stephen Touset Sep 12 '16 at 21:56
4
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I appreciate your answer here. I was definitely thinking in terms of AES blocks, not the 16KiB (application) blocks. $\endgroup$ – mikeazo Sep 12 '16 at 16:00
  • $\begingroup$ Great answer, thank you! Like i said, there will be 16 KiB sized fragments, so we have 1024 blocks in a fragment. Now i'm thinking about using CBC with a unique IV for each 16B block, in sequential order: 0, 1, 2, ..., 1024. Do you think that it would solve the problem you've mentioned? $\endgroup$ – yahavi Sep 12 '16 at 17:43
  • 1
    $\begingroup$ No, because CBC should be used with an unpredictable IV. It would work with e.g. CTR mode encryption, but note that if the IV needs to be 16 bytes that you'd have to make sure that the nonce makes up the first 8 bytes. In CBC mode you could encrypt your counter with the cipher in unpadded ECB mode and use the result as IV. $\endgroup$ – Maarten Bodewes Sep 12 '16 at 17:46
  • $\begingroup$ With your help, i decided to choose the CTR. The operation need to be fast, so i prefer not to encrypt the IV. "if the IV needs to be 16 bytes that you'd have to make sure that the nonce makes up the first 8 bytes" - I don't understand this. Can you explain please? Thanks! $\endgroup$ – yahavi Sep 14 '16 at 16:33
  • $\begingroup$ Well, the IV value will be used as the start of the counter value. After that it just goes on counting (in Big Endian mode, like Java). So if you put the nonce at the end you counters will repeat (fragment 1 counter values 00, 01, 02 ..., fragment 2 counter values 01, 02, 03 .... To make sure you don't make mistakes, encrypt two or more fragments of data and look for repetition in the 16 byte blocks of data. If you find any repetition, you're in trouble. $\endgroup$ – Maarten Bodewes Sep 14 '16 at 16:36
3
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ @ilkkachu, so with the proposers method, they would have 16KiB of ciphertext and 16-32 KiB of keying material (depending on if you are using AES 128, 192, or 256). Using CBC, however, you would have 16KiB of ciphertext, 16 bytes for the IV, and 16-32 bytes of keying material (again, depending on if you are using AES-128, 192, or 256). $\endgroup$ – mikeazo Sep 12 '16 at 13:23
  • $\begingroup$ "This is a significant win for storage and is also a win for storage as you can compute the key schedule once (with AES)." storage #2 -> efficiency? Not that I think that efficiency would be improved much, mind you. $\endgroup$ – Maarten Bodewes Sep 12 '16 at 14:46
  • $\begingroup$ @MaartenBodewes, yes, efficiency. Like you said, maybe not much improved, but if you are computing 1000s of key schedules for 1000s of random keys for each block, maybe. $\endgroup$ – mikeazo Sep 12 '16 at 15:44
  • $\begingroup$ Many thanks for the comments. There is a good reason why i'm using random keys, but i can't elaborate here about that due to business confidentiality reasons. Anyway, there will be a single key for each 16KiB block and not 16B. Moreover, my application already check for block's integrity. @ilkkachu - Can you elaborate why zero IV can help? Another question - If i'm using zero IV, will it be decipherable in a different OS? $\endgroup$ – yahavi Sep 12 '16 at 17:32

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.