Jim has a good point. Data at rest (stored on the disk platters) must be fully encrypted. If there is some information attached, which is not considered data (address, metadata, data-age, error correction code, etc.) we could offer the option to leave it in the clear. For example, the age of the data could trigger the disk hardware to refresh the sector, even when the key has not been set up. On the refreshed sector, new error correction code is to be calculated.
Accordingly, P1619 should offer a choice to start the encryption in a sector at a certain byte offset and run for a certain length only, leaving possibly unencrypted data in the beginning and end of the sector. This has to be uniform in the key scope, and part of the information block describing the crypto on the drive (also in the XML document): Key, Key_Scope, Sector_size, Crypto_Start, Crypto_Length. If the disk drive is file system aware (OSD), it was natural to implement a background defragmenter. With LRW-AES it cannot be done without the drive knowing the key and re-encrypting the data, unless LBA's are replaced with something else, like the FileID (unique 64-bit number for files on disk drives of multiple partitions) concatenated with the block offset within the file. How about offering an option for this? Laszlo > -------- Original Message -------- > Subject: Re: Procedure for 1619 (disk) > From: james hughes <[EMAIL PROTECTED]> > Date: Tue, January 17, 2006 1:53 pm > To: james hughes <[EMAIL PROTECTED]> > Cc: Shai Halevi <[EMAIL PROTECTED]>, SISWG <[EMAIL PROTECTED]> > > I have just taught myself a lesson not to schedule deadlines over > holidays. Workgroup participation is spotty, and I am just now > getting back into this and a lot seems to have transpired that I have > not been following... > > On Jan 17, 2006, at 9:18 AM, Shai Halevi wrote: > > * It seems that there is wide agreement for adding the "ciphertext > > stealing" method to handle odd-size sectors. This means that another > > subsection should be added to each of 4.3 and 4.4 (and some more test > > vectors should also be added). All of this should be doable within > > the next week or so (I think). > > While ciphertext stealing has been discussed (technically), do we > have consensus on how this will be used in the light of the T10 520 > byte sector format? > > I would hate to put this into the document and then have T10 say this > is of no use to them because our assumptions were naive? > > Jim
