On Mar 25, 2008, at 12:31 PM, Owens Bernard B wrote: > The nexus between the referenced article and this list seems to be > when Detective Sergeant Geoff Conway is quoted: "Encryption and > passwords hold no fear for us. If there is something on a computer, we
> will find it." Simson Garfinkel said: >My understanding is that there are several standard ways of attacking drive encryption: * Asking the suspect for the encryption key * Threatening the suspect to get the encryption key * Brute forcing the passphrase using other information around * Looking for the key in memory >But if you use strong passphrases and your users are torture-proof, they're probably on a pretty good footings. Although isn't clear that the good detective was considering an FDE solution, I would take exception to the above statement: 1. FDE solutions only protect the data when the computer has been powered down, and in the case of software FDE, only after five minutes or so have passed, because of the cold boot attack and other attacks. 2. Threatening the suspect with jail time or torture may or may not work, depending on the jurisdiction, although it presumably won't work in the case of a stolen laptop (unless the Mafia stole it along with your kids.) 3. Brute-forcing the password with an offline attack is much easier than most people realize, and is why we urge users to use two-factor authentication with a hardware token to control their encryption keys. Consider the following. Assuming you use a completely random password generator to generate printable characters from the standard 96-character keyboard, that amounts to about 6.5 bits of entropy per character. If you use numbers only, or natural language words, the entropy drops to about 3.3 bits per character. Most people have trouble remembering more than 8 random characters. That amounts to 52 bits of entropy, or less than single-DES strength, which as we know can be broken in less than a day with comparatively modest resources - maybe even by the Metropolitan Police. If numbers or words are used for an equivalent of a 26-bit key, a high-school kid could break it on his PC in an afternoon. Now, if the password mechanism uses PKCS#5 to slow down the logon process deliberately, this might have the effect of adding some additional resistance. Let's assume that an attacker might be able to compute a password hash in a microsecond, but that PKCS#5 is used to cause that to take 1 second per trial. That adds a factor of 10^6, or another 20 bits of entropy. Now we are up to the equivalent of a 72-bit key. But NIST is requiring at least 80-bit cryptography be used today, and at least 128-bit keys for information that will have a useful life past 2030. That would require a 16-character fully random password, and if you want to match the strength of AES-256, a 35-character password would be required! If you aren't using two-factor authentication with a hardware token that enforces a hard limit on the number of incorrect PINs, then yes, you are risk of merely annoying your users and fooling yourself into thinking that you have more than passable security. Bob _______________________________________________ FDE mailing list [email protected] http://www.xml-dev.com/mailman/listinfo/fde
