21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

gle time you want to protect a modified version of that chunk. You cannot just make<br />

incremental changes, then reencrypt with the same nonce.<br />

In fact, even for modes where sequential nonces are possible, they really don’t make<br />

much sense in the context of file encryption. For example, some people think they<br />

can use just one CTR mode nonce for the entire disk. But if you ever reuse the same<br />

piece of keystream, there are attacks. Therefore, any time you change even a small<br />

piece of data, you will have to reencrypt the entire disk using a different nonce to<br />

maintain security. Clearly, that isn’t practical.<br />

Therefore, no matter what mode you choose to use, you should choose random initial<br />

values.<br />

Many people don’t like IVs or nonces for file encryption because of storage space<br />

issues. They believe they shouldn’t “waste” space on storing an IV or nonce. When<br />

you’re encrypting fixed-size chunks, there are not any viable alternatives; if you want<br />

to ensure security, you must use an IV.<br />

If you’re willing to accept message expansion, you might want to consider a highlevel<br />

mode such as CWC, so that you can also incorporate integrity checks. In practice,<br />

integrity checks are usually ignored on filesystems, though, and the filesystems<br />

trust that the operating system’s access control system will ensure integrity.<br />

Actually, if you’re willing to encrypt and decrypt on a per-file basis, where you cannot<br />

decrypt the file in parts, you can actually get rid of the need for an initialization<br />

vector by using LION, which is a construction that takes a stream cipher and hash<br />

function and turns them into a block cipher that has an arbitrary block size. Essentially,<br />

LION turns those constructs into a single block cipher that has a variable<br />

block length, and you use the cipher in ECB mode.<br />

Throughout this book, we repeatedly advise against using raw block cipher operations<br />

for things like file encryption. However, when the block size is always the same<br />

length as the message you want to encrypt, ECB mode isn’t so bad. The only problem<br />

is that, given a {key, plaintext} pair, an unchanged file will always encrypt to the<br />

same value. Therefore, an attacker who has seen a particular file encrypted once can<br />

find any unchanged versions of that file encrypted with the same key. A single<br />

change in the file thwarts this problem, however. In practice, most people probably<br />

won’t be too concerned with this kind of problem.<br />

Using raw block cipher operations with LION is useful only if the block size really is<br />

the size of the file. You can’t break the file up into 8,192-byte chunks or anything<br />

like that, which can have a negative impact on performance, particularly as the file<br />

size gets larger.<br />

Considering what we’ve discussed, something like CBC mode with a randomly chosen<br />

IV per block is probably the best solution for pretty much any use, even if it does<br />

take up some additional disk space. Nonetheless, we recognize that people may want<br />

to take an approach where they only need to have a key, and no IV or nonce.<br />

214 | Chapter 5: Symmetric Encryption<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!