>> I'm not so sure about AES, but its predecessor DES is very, very easy to
>> implement in hardware.
>
> AES (and, really, almost all the modern block cyphers) are designed that
> way. They're all designed to run on smart cards and stuff like that,
> except for the "fish" ciphers (blowfish, twofish, etc), iirc, which are
> specifically designed to be fast in software.

Well, there's "easy" and there's "really easy". DES is really easy. AES 
I'm not so sure about, off the top of my head.

But sure. None of these ciphers are "hard" to implement in hardare.

>> Mmm, I wonder if it's immune to side-channel attacks? >:-D
>
> Well, first you have to get to the chip in its encrypted state or
> something. I'm (personally) not so worried about it that I think
> someone's going to crack the case open and hit it with a logic probe.

You don't have to open the case for side-channel attacks to be effective.

Maybe if you sent certain requests, the timing of the responce varies in 
a way that tells you something about the encryption key or the password 
hash or the PRNG state. Maybe you can measure power consuption and find 
out useful info. Heck, maybe the temperature varies, or it leaks RF signals.

Come to think of it, /that/ is the kind of thing I would expect FIPS 
certification to be testing for. Anyone can implement AES correctly. 
It's not hard to run a few test vectors and confirm that you get the 
correct numbers. Making sure that the assembled system is actually 
secure is a whole other matter...

> Indeed, I haven't found any review that actually says it's encrypting
> the data on the chip itself. If it can change the password instantly,
> I'd doubt the actual data is encrypted. I did read one review where they
> cracked it open, took out the battery for a couple weeks, put it back
> together, and the PIN was still enabled.

I looked at the FIPS documentation for one of the drives. (Not the one 
in the list I gave you, but something similar.) It actually describes, 
in vague detail, how the encryption works. It seems it stores the 
encryption keys in the clear (?!), and also stores the SHA-1 hash of the 
password. So presumably when you change the password, it just updates 
the SHA-1 hash.

To me, that seems like a very strange way to implement. However, there's 
no particular reason why you can't use the SHA-1 hash of the password to 
AES-encrypt the main AES encryption key. And then changing the password 
is /still/ instant, without having to re-encrypt any data.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message