In this post I'm going to explain how SafeHouse uses passwords to protect your data.
This is an advanced posting. You do not have to know any of this information to use SafeHouse disk encryption. I'm presenting this material simply because people who are evaluating our product and who are also somewhat familiar with cryptography have a desire to know what's actually going on under the hood.
The first thing to know is that when cryptography is done right, the methods and techniques employed do not have to be kept secret. In describing the process used by SafeHouse to work with passwords as I'll do below, I'm not giving away any secrets that would help anyone have a better chance at cracking our product or gaining access to files encrypted with SafeHouse. In fact, the techniques I'll be describing are in common use in many products and are very nicely documented in the excellent book, Applied Cryptography, by Bruce Schneier.
When you choose a password in SafeHouse to protect your files, this password is not directly used to encrypt your data. Instead, the password is used indirectly in the encryption scheme in a manner which actually increases security and at the same time provides a number of conveniences.
Passwords are often the weak point in any encryption product where the user is responsible for choosing passwords. People tend to choose passwords which are either too short or are based on their pet's name or birthday. And don't get me started about passwords written on sticky notes taped to computer screens.
To help combat the problem of weak passwords, SafeHouse uses a randomly chosen binary encryption key to directly encrypt your files. When you hear about encryption strengths being stated as 128, 256 or even 448 bits, this number is actually the length of the randomly chosen key.
SafeHouse Personal Edition always creates new volumes using 128-bit keys; while our Professional Edition supports 128-, 256- and 448-bit keys.
But we're only getting started. Also assigned to each newly-created volume is a 1024-bit salt and a 32-bit iteration count. Both of these values are randomly chosen by the SafeHouse programming and permanently assigned to the volume and stored in its file header. There is nothing secret about these values, however, they play a very important role in the overall scheme.
The text password you choose is then turned into a hash, or digest, using a cryptographic process called PBKDF2. Besides needing your password, this process also requires the aforementioned salt and iteration count as inputs. These various inputs are all jumbled together in a complex way which yields a secure digest which looks nothing at all like your original password and cannot be reversed back into your password. We call this the password digest.
One of the advantages of using a password digest is that the PBKDF2 algorithm tends to give short passwords a boost in strength due to how it slices and dices. And the salt and iteration values add further randomization so that the resulting digest will be different even when two separate people choose the same exact password.
We're finally nearing the end of this long-winded complicated explanation.
Remember that randomly-chosen encryption key (several paragraphs up)? That key is itself encrypted using the password digest as the encryption key, and the result is stored in the file header of your SafeHouse volume. This is perfectly safe because it's encrypted.
In the end, your password is never stored anywhere. It exists in memory for moments at a time and is then discarded. When you attempt to open a volume using your password, the password digest is once again computed and then used to decrypt the encryption key stored within the volume. Provided the encryption key passes a number of validation tests, it is then used to directly encrypt/decrypt your personal files being protected by SafeHouse.
One other thing that I should point out is that by using passwords indirectly as we do, it makes password changes very quick and simple because we only need to adjust a few things in the volume's file header. Had we used your password to directly encrypt file data, then a password change would require a sweep through the entire set of data - which might be hundreds of gigabytes and take several minutes or even hours to process. This would not only be extremely inconvenient, but it would also introduce unnecessary risks when you consider that it's possible you might lose power or have some other system crash half way through -- leaving you digging for you last backup.