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

Improve this question
$\endgroup$
4
  • 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, 2016 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, 2016 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, 2016 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, 2016 at 21:56

2 Answers 2

Reset to default
5
$\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.

Improve this answer
$\endgroup$
7
  • $\begingroup$ I appreciate your answer here. I was definitely thinking in terms of AES blocks, not the 16KiB (application) blocks. $\endgroup$
    – mikeazo
    Sep 12, 2016 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, 2016 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, 2016 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, 2016 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, 2016 at 16:36
4
$\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.

Improve this answer
$\endgroup$
4
  • $\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, 2016 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, 2016 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, 2016 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, 2016 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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