Saqib Ali wrote: > Well for one thing, any software based FDE is extremely slow, doubles > the file access times, and is a serious drain on the laptop battery.
Here's the relevant excerpt of the Elephant paper [0]: "A typical desktop machine today has a 3 GHz P4 CPU and a hard disk that can read at about 50 MB/s. That means that the CPU has 60 clock cycles for each byte that the disk reads. Laptops have slower CPUs, often around the 1 GHz mark. Laptop disks are also slower but not by nearly as much. (For example, the Seagate Momentus 5400.2 laptop drive can read data at almost 50 MB/s.) Our data shows that laptops tend to have fewer CPU clock cycles per byte read from disk, down to 40 or even 30 cycles per byte. We cannot predict what the CPU/disk speed ratio will be for the actual hardware that BitLocker will run on, but these numbers are the best guidelines we have. If decryption is slower than the peak data rate of the disk, the CPU becomes the bottleneck when reading large amounts of data. This is very noticeable, both because of the reduced performance and because of the reduced responsiveness of the UI when all CPU time is being used to decrypt data.2 Therefore, decryption, including all overhead, must be faster than the disk to get an acceptable user experience. BitLocker is carefully designed to overlap the reading of data from disk with the decryption of previously read data. This is only possible to a limited extent, and when the disk finishes reading the data, the CPU still has to decrypt (some of) the data. Thus the decryption time increases the latency of the disk request and reduces performance accordingly. This obviously argues for a fast decryption algorithm. A software implementation of AES runs in around 20–25 cycles per byte on a P4 class CPU. (Synthetic benchmarks can achieve somewhat higher speeds, but they exclude various overheads encountered in real system implementations.) Other overhead adds around 5 cycles per byte for a total of 25–30 cycles per byte. Based on this data, our performance analysis concluded that a single pass of AES, for example using AES in CBC mode, would have acceptable performance. An algorithm twice as slow as AES (45–55 cycles/byte) would be on the edge of being unacceptable, and a high-risk choice given the many uncertainties in the analysis. Anything slower than that would be unacceptable." > What if the encryption key for the Seagate's HDD can be managed using > TPM, i.e. wrapped, bound and stored on the TPM. The user will just > have to authenticate to the TPM, using a Token or a static password, > then the FDE encryption key will be available to the HDD.... Will this > solve the problem? I don't think so. The key thing to recognize is that BitLocker, in its least secure setting (no hardware tokens or USB keys), still improves security dramatically, while requiring no setup whatsoever. Hardware FDE does approximately the same thing security-wise, not nearly as flexibly, and requiring a lot of up-front setup (and that's assuming your TPM does rekeyable hardware tokens at all). And if we've learned anything from the negligible global uptake of encrypted e-mail and FDE suites such as PGP Drive, it's that security only works is if it can be engaged without requiring anyone -- that's the user, the system administrator, and all the way up to the CIO -- to think. The exceptions are exceedingly rare. But maybe I'm just a cynic. [0] Ferguson, Niels. AES-CBS+Elephant diffuser, A Disk Encryption Algorithm for Windows Vista. http://ln-s.net/FFZ -- Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]