Charlie asked me to forward this. From: "Charlie Kaufman" <[EMAIL PROTECTED]> Sent: Tuesday, March 08, 2005 12:46 PM To: cryptography@metzdowd.com Subject: Re: comments wanted on gbde
Steve Bellovin writes: >A "discussion" -- I'll be polite and call it that -- has erupted on >some mailing lists about gbde -- geometry-based disk encryption. With >the author's consent, I'm soliciting opinions from this group about it: >http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf My biggest complaint with the cryptographic design is that it is overly complex for no good reason. Adding extraneous complexity is much more likely to introduce security problems than to mask them, but it seems unlikely that it did so in this case. This design is likely plenty secure for realistically expected uses. The paper acknowledges the "cleaning lady copy attack", where periodic copies are made and differences noted. In this case, the attacker can identify the sectors that were updated. With these patterns, it is likely no security is gained by the complex rearranging of sectors in the algorithm. But this was only a backup mechanism anyway. The three most serious "room for improvement" areas I could find are: 1) There is no integrity check on the encrypted sectors. An attacker can therefore make modifications to the data that the user will not detect cryptographically. Since CBC mode is used on individual sectors, an attacker can make a predictable change to a chosen block if he accepts a random change to the following block. One can imagine (with a good imagination) the ability to patch a block of a program to behave in an insecure way. 2) The paper notes that someone who knows an old passphrase (and has access to a small amount of old data) will be able to read the disk. This largely negates the value of periodically changing the passphrase. The straightforward solution of decrypting and reencrypting the entire disk when the passphrase changes is noted as having unacceptable performance. An alternative whose performance might be acceptable is to encrypt the old key under the new key, keep that in the header, and encrypt newly encrypted sectors with the new key. A background task could decrypt and reencrypt all sectors over time. 3) Attention should be paid to failure modes. One can imagine disk failures - possibly even a sector written without its corresponding key sector written -that would render much or all of the disk inaccessible. Understanding the transaction semantics of the disk controller is required to get this right (in the worst case, writing multiple copies of critical data where the second write is not initiated until the first completes). My reading of the document is that the master record is written on the disk in four places for redundancy against corruption, but the locations of those master records is kept in only one place. --Charlie Kaufman --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
