Re: encrypted file system issues (was Re: PGP master keys)
[A bit off topic but I thought I'd let it through anyway. Those uninterested in OS design should skip the rest of this message. --Perry] On 5/1/06, [EMAIL PROTECTED] (Perry E. Metzger) wrote: Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, so if the atomic disk block write assumption is correct (and almost all modern file systems operate on that assumption), you have no more real risk of corruption than you would in any other application. I haven't seen the failure specs on modern disk systems, but the KeyKOS developers ran into an interesting (and documented) failure mode on IBM disks about 20 years ago. Those IBM systems connected disks to a controller which was connected to a channel which was a specialized processor with DMA access to the main storage of the system. Note that these systems were designed in the days when memory was expensive, so there was an absolute minimum of buffering in the channel, controller, and disk. There are many possible failure modes, including power failure on the individual components, hardware failure/microprogram failure in the components, etc. The failure we experienced was a microcode hang in the channel (probably caused by a transient hardware failure), which also stopped the CPU. The failure occurred while the controller and disk was writing a block, and the channel ceased providing data. The specification for the controller was if the channel failed to provide data, it filled the block with the last byte received from the channel. If the channel and CPU had been running, the overrun would have been reported back to the OS with an interrupt. As it was, all we had was a partially klobbered disk block. Since KeyKOS was supposed to be a high reliability OS, we needed to code for this situation. Because of the design of the disk I/O system, there were only two disk blocks (copies of each other) where this kind of failure could cause a problem. We defined the format of these blocks so the last two bytes were 0xFF00. By checking for this pattern, we could determine if the block has been partially klobbered. We then had to ensure that we checked for correct write on one of the blocks before starting to write the other. Does anyone have any idea how modern disks and computers handle similar situations? Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
encrypted file system issues (was Re: PGP master keys)
Travis H. [EMAIL PROTECTED] writes: Does anyone have any experience with disk or filesystem encryption, especially with regard to unclean shutdowns and power failures? Normal file systems are designed to fail in ways that are easy to clean up with fsck, but when you start to throw encryption into the mix, it seems like you can easily end up with something unrecoverable. Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, so if the atomic disk block write assumption is correct (and almost all modern file systems operate on that assumption), you have no more real risk of corruption than you would in any other application. The only real risk points come in if you're doing a re-key of the entire disk or some similar operation in which care must be taken with the design or you could leave yourself in an unknown state. Even without encryption I've seen apparent bugs in ext2fs on SMP machines that lead to sectors of nulls placed in files that were being written around the time the system crashed. Bugs happen in everything. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted file system issues (was Re: PGP master keys)
On 5/1/06, Perry E. Metzger [EMAIL PROTECTED] wrote: Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, So is it vulnerable to any of the attacks here? http://clemens.endorphin.org/LinuxHDEncSettings I used to run NetBSD 1.6 IIRC, and for some reason cgd was in previous and later releases but not that one. I found that puzzling. -- Curiousity killed the cat, but for a while I was a suspect -- Steven Wright Security Guru for Hire http://www.lightconsulting.com/~travis/ -- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: encrypted file system issues
Travis H. [EMAIL PROTECTED] writes: On 5/1/06, Perry E. Metzger [EMAIL PROTECTED] wrote: Not if you design it correctly. Disk encryption systems like CGD work on the block level, and do not propagate CBC operations across blocks, So is it vulnerable to any of the attacks here? http://clemens.endorphin.org/LinuxHDEncSettings Yes, but they are all uninteresting. For example, yes, it is trivially true that if two 128 bit ciphertext blocks are identical that you can extract some information about those two blocks, but that only reveals information about two blocks and the odds of this happening are microscopic. I used to run NetBSD 1.6 IIRC, and for some reason cgd was in previous and later releases but not that one. I found that puzzling. So do I, since it isn't true. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]