FreeOTFE (on the fly encryption) most secure ?

It seems that the latest FreeOTFE http://www.freeotfe.org/ offers the newest method XTS for it's volumes

I know that Truecrypt only offers LWR and in the past also CBC.

XTS is XEX-based Tweaked CodeBook mode (TCB) with CipherText Stealing (CTS). Although XEX-TCB-CTS should be abbreviated as XTC, “C” was replaced with “S” (for “stealing”) to avoid confusion with a well-known drug that is illegal in most countries. Ciphertext stealing provides support for sectors with size not divisible by block size, for example, 520-byte sectors and 16-byte blocks. XTS-AES is currently considered by SISWG for the IEEE P1619 draft Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices.

XTS is employed by the FreeOTFE disk encryption system to increase security.

LRW issue

From the year 2004 to the year 2006, drafts of the P1619 standards were using AES in LRW mode. In the Aug 30, 2006 meeting of the SISWG, a straw poll showed that most members would not approve P1619 "as is". Consequently, LRW-AES has been replaced by the XEX-AES tweakable block cipher in P1619.0 Draft 7 (and renamed to XTS-AES in Draft 11). Some members of the group found it non-trivial to abandon LRW, because it had been available for public peer-review for many years (unlike most of the newly suggested variants). The issues of LRW were:
An attacker can derive the LRW tweak key K2 from the ciphertext if the plaintext contains K2||0n or 0n||K2. Here || is the concatenation operator and 0n is a zero block. This may be an issue for software that encrypts the partition of an operating system under which this encryption software is running (at the same time). The operating system could write the LRW tweak key to encrypted swap/hibernation file.
If the tweak key K2 is known, LRW does not offer indistinguishability under chosen plaintext attack (IND-CPA) anymore, and the same input block permutation attacks of ECB mode are possible. Leak of the tweak key does not have an impact on the confidentiality of the plaintext.


so it seems that FreeOTFE is the first to use this method. I really like the low memory usage from this program.

I know that the GUI is not the most beatifull, but if it implements the algorithms secure i really don't mather. After all, you don't use strong encryption for the looks


Waldo

 

I'm interested in the issue of data granularity, when juxtaposing narrow-block modes (e.g., LRW, XEX, and XTS) with wide-block modes (e.g., CMC, EME, and XCB). With LRW, an adversary can basically randomize a block of plaintext; that is, a changing one ciphertext block renders a random change to the corresponding plaintext block. Such a mode doesn't provide authentication, in the sense of MAC; however, LRW is often used in environments that can't afford a MAC. Because of that, you might shoot for something called "poor-man's authentication." In other words, you allow the adversary to manipulate ciphertext, and hope that it's more likely for such manipulation to cause the system to crash, before providing any useful service to the adversary.

While LRW achieves this to a certain level, it operates on the relatively short block length of 16 bytes (i.e., the AES), which gives the adversary some freedom. For example, here's a potential attack scenario outlined by Niels Ferguson, assuming LRW is the mode of operation:

To mitigate the effects of this, the BitLocker design team modeled their block cipher, AES-CBC + Elephant diffuser, as operating on large blocks of 512-8192 bytes. The attack is still possible, but is much more difficult to mount, since any attack point is less likely to be on a suitable block boundary and it requires that an adversary randomize more plaintext, which is more likely to result in a system crash.

(CMC and EME were the top contenders of the potential solutions that BitLocker's design team looked out, but they're patented, unfortunately. Although they were designed for just what the BitLocker design team had in mind, and had the security properties they wanted, they hadn't been widely studied, making them a security risk, and they required two AES encryptions per block, making them a performance risk.)

All in all, diffusion over a wide block seems to be the state of the art. You can check out the BitLocker specifications here. (Most everything I've said here is found there.) On a related note, there has been some interesting work recently, at UNC-Chapel Hill, in integrity preservation that, among other things, doesn't change the block size. You can check it out here and here. You might find it useful.

I've neither looked at TrueCrypt (LRW) nor OTFE (XTS) closely enough to determine how, if at all, this attack would apply, given that they're both using narrow-block modes. I'll pass this along to the developers. In the meanwhile, is there anyone here with an intimate knowledge of TrueCrypt's internal guts?

 

Justin, I'm not sure why you have not taken the time to look at TrueCrypt yourself. It is the world's most downloaded open-source encryption application.

Here's the source code:
http://www.truecrypt.org/downloads2.php

 

Fine granularity of LRW.

I've seen some of its source in the past, by looking at TrueCrypt itself, and other sources (i.e., Brian Gladman's code). However, I haven't had the time to give it a thorough look, in order to make any concrete statements. Couple that with the fact that I'm not an expert in secure programming habits, and it's inevitable that I would overlook something, without some time to devote to it.

I was curious to know if anyone here, with a precise understanding of how TrueCrypt handles data, could verify whether or not data modification attacks are possible, due to the fine granularity of LRW. I'll make an effort in the near future to give TrueCrypt a better look, and run these things by the developers. At the moment, I'm dividing my time between two continents, with little left over!

Cheers!

 

Re: Fine granularity of LRW.

Understood. I'm too damn busy to turn around myself. I'm ready for a vacation but, alas, no time soon.