On Jan 15, 2011, at 8:53 44AM, Marsh Ray wrote: > On 01/14/2011 06:13 PM, Jon Callas wrote: >> >> This depends on what you mean by data integrity. > > How about "an attacker with write access to the disk is unable to modify the > protected data without detection"? > >> In a strict, formal >> way, where you'd want to have encryption and a MAC, the answer is no. >> I don't know of one that does, but if there *is* one that does, it's >> likely got other issues. > > How come? Is there some principle of conservation of awesomeness at work or > something? > >> Disks, for example, pretty much assume that >> a sector is 512 bytes (or whatever). There's no slop in there. It >> wouldn't surprise me if someone were doing one, but it adds a host of >> other operational issues. > > If the crypto driver is functioning as a "shim" layer on top of a block > device it seems reasonable that it could reduce the overall size seen by > upper layers and remap the actual storage a little bit. > > A 256-bit hash takes 32 bytes, 1/16th of the 512 byte sector size. So a > encrypting driver could simply map 15 blocks onto 16 hardware disk blocks. > This might impose very little overhead since the minimum number of blocks in > the smallest IO operation goes from one to two, but this may not be > noticeable. My understanding is that the 512-byte block size is mainly used > by the disk bus protocols and the lower- and higher-layers (e.g. RAID, > filesystems, virtual memory) will operate on 4-8K blocks and not hit that > minimum anyway. The disk itself can be expected to do a fair amount > read-ahead caching too. > >> However -- a number of storage things (including TrueCrypt) are using >> modes like XTS-AES. These modes are sometimes called "PMA" modes for >> "Poor Man's Authentication." XTS in particular is a wide-block mode >> that takes a per-block tweak. This means that if you are using an XTS >> block of 512 bytes, then a single-bit change to the ciphertext causes >> the whole block to decrypt incorrectly. > > But how does anyone know that it decrypted incorrectly without some integrity > checking? It seems like any integrity scheme will have upper bounds on its > security related to the number of bits dedicated to that purpose.
See http://www.cs.unc.edu/%7Ereiter/papers/2007/USENIX1.pdf and http://www.cs.unc.edu/%7Ereiter/papers/2005/NDSS.pdf --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
