>>> If you want data security and don't like destroying your hardware,
>>> SED ("sel$
>> You're assuming that the SED doesn't store an extra copy of the
>> decryption key in NVM or on the medium.That was my initial reaction too! >> Also, reverse-engineering has shown that at least some SEDs have >> very bad crypto implementations. I was not aware of that, but (and this is a depressing commentary on _something_) it does not surprise me in the least. >> Even if your SED doesn't have a back door or badly implemented >> crypto, you also have to worry about whether someone has managed to >> install compromised firmware on it. > The key here is the use of signed firmware, which I believe is the normal pr$ That's hardly a fix; all it does is somewhat reduce the pool of people who can create the compromised firmware. I don't trust the vendor's internal security to keep the key from leaking and I don't trust the vendor's HR security to prevent malware authors from making it to the inside, and I *sure* don't trust the vendor to resist a request from law enforcement for an easy-to-access backdoor (which will, of course, promptly get abused, either by others or for other purposes). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
