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.

Improve this question
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.

Improve this answer
  • 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 Jan 8 '14 at 22:12
  • A simple counter is not indistinguishable from random. It is obviously trivial to predict the next value. – Stephen Touset Jan 8 '14 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. – Stephen Touset Jan 8 '14 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 Jan 8 '14 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. – Stephen Touset Jan 9 '14 at 1:00

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.