Problem - Kevin Tafuro

gle time you want to protect a modified version of that chunk. You cannot just make
incremental changes, then reencrypt with the same nonce.
In fact, even for modes where sequential nonces are possible, they really don’t make
much sense in the context of file encryption. For example, some people think they
can use just one CTR mode nonce for the entire disk. But if you ever reuse the same
piece of keystream, there are attacks. Therefore, any time you change even a small
piece of data, you will have to reencrypt the entire disk using a different nonce to
maintain security. Clearly, that isn’t practical.
Therefore, no matter what mode you choose to use, you should choose random initial
values.
Many people don’t like IVs or nonces for file encryption because of storage space
issues. They believe they shouldn’t “waste” space on storing an IV or nonce. When
you’re encrypting fixed-size chunks, there are not any viable alternatives; if you want
to ensure security, you must use an IV.
If you’re willing to accept message expansion, you might want to consider a highlevel
mode such as CWC, so that you can also incorporate integrity checks. In practice,
integrity checks are usually ignored on filesystems, though, and the filesystems
trust that the operating system’s access control system will ensure integrity.
Actually, if you’re willing to encrypt and decrypt on a per-file basis, where you cannot
decrypt the file in parts, you can actually get rid of the need for an initialization
vector by using LION, which is a construction that takes a stream cipher and hash
function and turns them into a block cipher that has an arbitrary block size. Essentially,
LION turns those constructs into a single block cipher that has a variable
block length, and you use the cipher in ECB mode.
Throughout this book, we repeatedly advise against using raw block cipher operations
for things like file encryption. However, when the block size is always the same
length as the message you want to encrypt, ECB mode isn’t so bad. The only problem
is that, given a {key, plaintext} pair, an unchanged file will always encrypt to the
same value. Therefore, an attacker who has seen a particular file encrypted once can
find any unchanged versions of that file encrypted with the same key. A single
change in the file thwarts this problem, however. In practice, most people probably
won’t be too concerned with this kind of problem.
Using raw block cipher operations with LION is useful only if the block size really is
the size of the file. You can’t break the file up into 8,192-byte chunks or anything
like that, which can have a negative impact on performance, particularly as the file
size gets larger.
Considering what we’ve discussed, something like CBC mode with a randomly chosen
IV per block is probably the best solution for pretty much any use, even if it does
take up some additional disk space. Nonetheless, we recognize that people may want
to take an approach where they only need to have a key, and no IV or nonce.
214 | Chapter 5: Symmetric Encryption
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.