On Fri, Feb 11, 2011 at 9:22 PM, Ken Schaefer <[email protected]> wrote: > I’m still kinda confused. The post way back at the beginning of the thread > is talking about device encryption. Typically whole disk encryption doesn’t > use a <15 character password – but rather a somewhat longer encryption key. > No such thing as a “rainbow table” for encryption keys that I’m aware of.
Well, yes and no. According to the report, the iPhone apparently doesn't encrypt the payload (encrypted data) with anything derived from the user's password, but rather with some other locally-stored and unprotected key. Since that key is available to the attacker, the attacker can decrypt the payload. If the password was stored as a hash (inside the payload or not), one might be able to pre-compute hashes, yielding a rainbow table. Obviously, the alleged design is poor. I believe the design generally thought to be best is: The user has a password (phrase/code/PIN/etc.). Call that P1. Ideally, the local storage is protected by a cryptographically random key. Call that K1. K1 is stored locally (on the device), ciphered using another key. Call that K2. K2 is derived from P1 somehow. If K2=P1, then one could have a partial rainbow table of K1 keys resulting from common passwords. So that's possible. But a good design runs P1 through various transformations first. You can add a salt to P: When K1 is first encrypted, you generate some additional randomness. That's the salt. You store the salt in the clear on the device. You combine P1 with the salt to yield P2. K2 is then derived from P2. With a large salt -- say, 64 bits -- each possible P1 has 2^64 possible P2 results. You can add multiple rounds of hashing. Combine P1 and the salt, and hash that to produce H1. Combine H1 with the salt, and hash that to produce H2. Repeat as desired. Derive K2 from the final hash. By increasing the computation required for a given password+salt combination, you make large scale pre-computation that much more expensive. Techniques like this make rainbow tables useless for anything but the most common of passwords. By my (admittedly suspect) calculations, with a 64-bit salt and a 128-bit K2, you would need 256 exabytes to store the rainbow tables for a *single* password. IIRC, no version of LM/NTLM authentication uses a salt, which is why they are so vulnerable to rainbow tables. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
