1

I'm working on a project that splits large files into several encrypted fixed-size blocks (e.g. 4KiB). Those blocks shall be used to be stored persistently on a storage device.

Blocks are encrypted symmetrically and each block has its own Initialization Vector. Unfortunately I am unsure how to "generate" those Initialization Vectors correctly:

As it is explained here and here there are several different Initialization Vector generation algorithms. Obviously, it has to be distinguished between private ones (e.g. ESSIV) and public ones (e.g. Plain). I also read that IV algorithms like Plain should not be combined with CBC mode of operation.

Which IV generation algorithm should I use? Or in other words: What should I definitely NOT do?

I don't want to use random nonces for each block, as those nonces would have to be stored somewhere - a IV generation algorithm would be much more comfortable to me.

1 Answer 1

1

TL;DR, the particular requirements of IVs depend upon the mode of encryption you're using. The one common attribute is that all IVs must be unique.

In modes like CTR and GCM, uniqueness is the only requirement. The IV in this case is also commonly referred to as a nonce (i.e., a "number used once"). Even a simple counter would suffice, as long as it is guaranteed not to ever generate a duplicate (even across multiple machines, or in the event of software failure).

In modes like CBC, the IV must be indistinguishable from random by an adversary.

For IVs with a large enough size (e.g., at least 128 bits), a cryptographically secure random number generator (CSPRNG) is usually considered sufficient. For algorithms involving IVs that are small enough such that random collisions are probable (for instance, Salsa20 has a 64-bit nonce), a CSPRNG is not appropriate since it would generate collisions. Another scenario where a CSPRNG might not be usable is in embedded devices, which may not have the ability to generate sufficiently random numbers in hardwaree.

5
  • Yes, but actually simple counters should not be combined with CBC, even if each IV is indistinguishable and unique. Is there any further literature discussing those issues? If I try to develop my own IV generation algorithm, how can i prove that it is secure? I thought about a generation scheme like ESSIV: SHA256(key) = first IV of sector 0, and then just incrementing that value.
    – rralf
    Commented Jan 8, 2014 at 22:12
  • A simple counter is not indistinguishable from random. It is obviously trivial to predict the next value. Commented Jan 8, 2014 at 22:14
  • 1
    In general, with cryptography, do not ever attempt to develop your own anything. Cryptography is kryptonite: the more of it you touch and the closer you are, the greater the danger. It is not possible to recommend an approach to selecting IVs without knowing first knowing what cipher and mode you are using, and what the intended purpose is. Commented Jan 8, 2014 at 22:19
  • Yes, that's exactly the reason why i'm asking what to use and what to do or not to do. My intended purpose is written in my question. Which mode+IV generation would you propose?
    – rralf
    Commented Jan 8, 2014 at 22:37
  • In general, I would recommend (in preferential order): 1. XSalsa20-Poly1305 (IV generated by CSPRNG), which is part of the excellent libsodium library. 2. AES in GCM mode (IV generated by CSPRNG), which is available in versions of OpenSSL later than 1.0.1. If you don't have access to either of those libraries (or algorithms), I would recommend you take whatever steps necessary to do so. Commented Jan 9, 2014 at 1:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .