On Sun, 12 Apr 2009, Lance Spitzner wrote: >> Typically the software FDE solution should intercept BIOS interrupt >> (I'm not >> Windows programmer, but back in old DOS times it was int 13h and >> 76h) and >> individually encrypt/decrypt each 512 bytes sector. It is very CPU- >> consuming >> process. Up to 48% of the CPU power can be spent on encryption. > > Really? I have PGP on my Mac and absolutely love it. In addition, I > have not seen any noticeable latency or performance impact, and I > hammer my system. Bruce Schneier also brings up a good
Like TrueCrypt, which also is without noticeable latency or performance impact. Or the Linux file system encryption stuff. > perspective[1], you may want to consider leaving your FDE to the > encryption experts (such as PGP) as opposed to hard drive > manufacturers. Don't get me wrong, I'm all for HD FDE as it can > simplifies things at the enterprise level, but lets not just start > throwing around numbers and poo pooing the software side. Last time I checked on HD FDE, from what sparse documentation I could find I concluded that it all boils down to your bootup password. From an enterprise point of view this is -I'm guessing- a bit unpractical as it hinders data recovery in case of password (ehr, carbon-based memory) loss. We decided to not go for HD FDE, even though a number of our Lenovo laptops supports it: if a laptop breaks you *must* have one again that supports it (not all do), and if a disk breaks you *must* have a spare disk that supports it. In our case with a rather mixed environment, this is not practical. But wasn't the question where to find information on this? I'd first and foremost dive into the linux partition encryption, and into the FreeBSD disk encryption (GBDE). Should be well documented and with readable code.. -- Jan _______________________________________________ FDE mailing list FDE@www.xml-dev.com http://www.xml-dev.com/mailman/listinfo/fde
