The following link has a presentation about the upcoming 'technology' in the Intel chipset Eaglelake. First of all, this sounds really interesting in terms of performance. It basically talks about embedding hardware encryption within the hard disk controller on the north bridge. http://inteldeveloperforum.com.edgesuite.net/fall_2007/d2/SCIS003/f.htm I apologize for posting this link. It will only play in Internet Explorer browsers and -- even worse -- for me, only after installing Windows Media Player 10. Feel free to flame Intel therefore. You can safely focus on minute 24. The rest of the presentation is about management stuff and hyping some 3rd party vendor's product (not interesting at all). However, it got me thinking whether I trust these solution. I inherently feel more secure when using software I wrote and compiled myself than using hardware. But what's the difference when the bitstream that tumbles out at both ends -- AES hardware and AES software -- are identical? I found for me that the argument that makes me uneasy is that hardware encryption is so much more specialized in use than a general purpose CPU. The intentions are so much more clear when using the API. The key when loaded into the chipset really stands out and capturing it is so much more easy; capturing can mean by sniffing the bus (which is technically almost impossible for attackers with limited budget, also the system has to be online, and you have to type in key material while the attack is in progress). What I'm more worried about is intentionally backdoored crypto hardware. Are we really so naive to believe that -- given the series of illegal (no search warrants, no respective law) cooperations of large business entities with the NSA[1] -- these guys will allow it to happen that Intel starts (significant market share) to deploy industrial strength encryption technology worldwide? Even if I'm not that paranoid that answer wholehearted "No" to this question, I'm still suspicious. The same task for backdooring CPUs is almost impossible. It is inherently hard to semantically decipher the stream of instructions by static/syntactic analysis. Tell apart the set of instruction that sets up an AES key from the instructions that does context switching, device management or displays the toolbar of your email client can't be done, hence no backdooring is possible, here. As said, for special purpose hardware it's all different. The API is clearly sketched out and tampering with the crypto chip itself would be the way to go if you are a large intelligence agency and your business consists of mass monitoring. I hope the community can produce good counter arguments to my reasoning above. I hope so because, otherwise I should start to push for performance of dm-crypt even without hardware assistance. -- Fruhwirth Clemens - http://clemens.endorphin.org --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
