So Nate Myers emailed me today to ask why I didn't just post a web page with the text of WiebeTech's press release about the product I developed for them instead of all these cryptic hints in my diary.
And I responded to Nate that his email was the first that I'd heard of WiebeTech announcing the product, and I didn't want to announce it before WiebeTech did.
(WiebeTech's press release is a Word document. Sorry. I'll ask them if it's OK that I post an HTML version.)
WiebeTech's FireWire Encrypt(TM) is an implementation of the Advanced Encryption Standard embedded in an Oxford 911 FireWire/IDE bridge. It encrypts each sector of the user's hard drive using the Rijndael block cipher.
It is designed to be portable and easy to use. Easy to use because the only software the user needs to install is a small applet to enter the passphrase. There is no complicated operating-system level software to install or configure. Portable because FireWire is a hot-pluggable technology for external devices.
A good use for the product would be to safely take confidential source code or business plans home from work on a hard drive, without fear that your secrets would be revealed if the hard drive were stolen.
WiebeTech will be demonstrating it on Mac OS X, but I plan to support it from Linux and Windows by the time the product is released to the public.
And yes, we're applying for a patent. But we're not applying for an algorithm patent. I disagree as much as anyone here with the abusive patents that the USPTO has been issuing the last few years, but I think this sort of thing is appropriate to patent.
Getting it to actually work was definitely novel and unobvious, and I believe that users will find it useful.
Someone emailed to ask me about what encryption mode FireWire Encrypt uses, and I thought I should post that here too.
It uses Cipher Block Chaining and Initialization Vectors.
Cipher block chaining is applied to each 16-byte block of a 512-byte disk sector. What you do is XOR the previous block's ciphertext over the next block's cleartext before encrypting subsequent blocks. This has the effect of making identical blocks of cleartext encrypt differently.
CBC can't be carried between disk sectors because the host can read or write each sector independently. To make identical sectors encrypt differently, I use an initialization vector.
What you do is XOR some value over the first block of cleartext in each sector before you encrypt it. The IV doesn't have the be kept secret. It doesn't even really matter what value you use, as long as each sector gets a unique IV. The simplest thing to do is to use the sector number as the IV.
I felt that was the best thing to do after reading about block cipher modes in Bruce Schneier's Applied Cryptography.
Initialization vectors work better than you might think because one of the characteristics of a strong encryption algorithm is that flipping a single bit in the plaintext will flip, on the average, half the bits in the ciphertext, with the bits that get flipped being apparently randomly distributed. So having only one bit of the IV being different from sector to sector will dramatically change the ciphertext.
I was also asked if the product checks that the user has entered the correct password. The version that will be demoed at MacWorld doesn't do that yet, but I think that verifying the password is very important for making the product accessible to regular users. I know a simple way I can do that, and plan to check passwords in the final released product.