At 01:13 AM 04/29/2002 -0700, [EMAIL PROTECTED] wrote: > [each cluster has 128 bits permanent half-key, 128 bits nonce half-key...] > are for the second cluster, and so on. Each time a disk cluster is > written to, a new temporary half-key is pulled from the (P)RNG and used > to encrypt the cluster data, and then is stored in the temporary key > file. When a cluster is read, the appropriate temporary key half is read > from the temporary key file, combined with the permanent key half, and > then the data is decrypted.
At least it's big enough to prevent searches through the space. But it not only requires managing the extra key-file (which could be pretty large, and needs to be kept somewhere, apparently not in the same file system), it potentially requires two disk reads per block instead of just one, which is a major performance hit unless you're good at predictive caching, and more seriously it requires two writes that both succeed. If you write the key first and don't write out the block, you can't decrypt the old block that was there, while if you write the block first and don't succeed in writing the key, you can't decrypt the new block. This makes depending on caching writes much more difficult - it's already one of the things that helps make systems fast and either reliable or unreliable, and you've made it tougher as well as requiring two disk spins. You can get some relief using non-volatile memory (the way the Legato Prestoserve did for NFS acceleration - first cache the write in battery-backed RAM, send your ACK, and then write the block out to disk), but that's hardwary. It's cute, though...
