Single device encryption - is sounds like a SHAm.

So let's deal with these cases one by one. Your smartphone likely picks a random encryption key that's used with AES-256, which is a symmetric cipher (not PKI). That key is encrypted with your PIN. So, no PIN, no key to decrypt. That said, if I can get malware on your device, I can log input, capture your PIN, and get your email. This is why most mobile devices have settings to wipe your device after N bad PIN entries: the security is all in the PIN. With your laptop, you're using public key encryption, which you're missing a step from. When you encrypt a message using a public key, what you're actually doing is selecting a session key, encrypting the message with the session key, encrypting the session key with the public key, and then sending the encrypted message and encrypted key to the other party. Private key is used to decrypt the session key, and the session key is used to symmetrically decrypt the message. There are a couple of different ways to do whole disk encryption on your laptop. One way is to prompt you for a password at boot, which is used to decrypt things. It's pretty easy to understand how the password is safe with this method. Another method, that's used by Microsoft's BitLocker and others is utilizing a special chip in your lappy called a trusted platform module (TPM) chip. Encryption with the TPM chip works like this: the password gets stored in the chip, which you can't just read out of. On boot, the TPM chip runs a checksum on special files in the OS to make sure tampering (malware, rootkit) hasn't occurred. If it has, halt, no boot. If no tampering is detected, it releases the key, which is used to decrypt the disk and get things functioning. Regarding 20 character passwords: you and others are not thinking about the problem correctly and understanding what rainbow tables are used for. Storing a password is very insecure -- you can read it. So we hash the password. You can use rainbow tables to attack these hashes -- precompute every hash for a given keyspace (e.g., all 8 character possibilities), and then do a lookup. We (the security community) know about this, though, so we also add a salt -- whenever we want to store a password securely, we generate a random value, combine it with the password in some way (normally concatenation, because this increases the size of the keyspace), and hash the result. A successful rainbow table against a salted password would require every key within the keyspace concatenated with every possible salt value precomputed. We're talking end of the Milky Way timescales here. In your 7zip example, this isn't even useful. The 7zip password isn't stored anywhere. When you type in the password, 7zip decrypts the start of the file and checks for a 7zip header. No header == bad password. Also, the computational cost isn't in generating every possible password -- that's dirt cheap. The computational cost is in the decryption operation, and you still have to pay that in your example. In the security field, whenever I or someone else is assessing a product, the encryption implementation is the first thing we look at. This is why software engineers are idiots if they don't use existing encryption libraries. They are _extremely_ well vetted, and because so many products use those libraries it's a _major_ event when someone finds an attack against a commonly used encryption lib. Basically, it makes a very sexy target to security folk.

In all your examples, the password is the point of security. It is the element hackers need to decrypt the data. If your password is short and guessable (e.g. in the dictionary, or a date), it can be brute-forced quickly. There are 839,299,365,868,340,224 possible 10 character passwords composed of upper and lower case alpha numerics. Trying 1000 passwords a second it would take 20 million years to try them all. And a rainbow table would use more storage than exists on the planet. Trying to brute force a 20 character password on a billion computers would take many times the age of the universe. That's where the security lies. Also, some encryption algorithms (like the one 7z uses) have a built in "work factor", meaning they are deliberately designed to take extra computing power to decrypt so brute force attacks take longer.

For your phone app, it's very possible there's a device-specific ID/GUID that's hardwired into the device that they use as part of the key to encrypt the data stored on the SD card. No device, no decryption. That at least saves you from the "lost SD card" attack, and possibly saves you from a naive "rogue app shipped off all my data" attack that doesn't include the per-device ID. "Generating all the keys for passwords up to 20 characters" is computationally infeasible. Even if the passwords are only lowercase alphabetic characters, and let's say it's 15 characters instead of 20, and let's say the output is only 1 byte, that's still 1500 exabytes of storage.

You're on the right track with your thinking about 7zip: in each of these cases, what's happening is that the software is using your password/PIN to generate a private key; that key is used to decrypt the contents. So, when you enter your PIN for the encrypted email program, it's converted into a private key used to decrypt your email. Similarly, PGP takes your password, passes it through an algorithm, and uses the key out the other side to decrypt your data. The term here is a http://en.wikipedia.org/wiki/Key_derivation_function: it's a way of taking a shorter key and turning it into a much longer one (e.g. 256 bits for AES-256). In each case, you're completely right that the weak point is the password. Breaking PGP itself will take many (many) orders of magnitude longer than brute-forcing the password. So the key to real security in all of these situations is picking https://xkcd.com/936/ Along these lines: if your email app really is using a 4-number PIN as a lock, then the AES stuff is essentially bullshit. If that's the case, they're selling you an iron safe (AES) with a glass door (the PIN).

I started to type justkevin's (and everyone else's) response, but he got there first. I'd add to that: Once you decrypt the data with a password, you still have to know if that data is valid or gobbledygook. With various cryptography challenges with shorter messages, it's been a big deal what language the message was in, so that you could look through for patterns that appeared to be a message. All of this is reiterating that, past the password, what you're trying to do is to make it computationally expensive enough to try all of the variations that nobody bothers. If you have to create the password, decrypt a file (or several files), and then look through that file to see if you've got something that looks like decrypted data, and you can make that step take a sizeable fraction of a second for the foreseeable future, that's the goal.

Actually, TPM is not particularly unusual. If anything, it's the gold standard at the moment. Additionally, your wording is a little ambiguous. Brute forcing the key is expensive because decryption is expensive (checking that first encrypted block to see if the header is correct), not because deriving the key from the password is expensive.

One thing to expand on with full-disk encryption: it's extremely unlikely that the encryption key is actually derived from your password. For one thing, this would mean that the entire disk would need to be decrypted and re-encrypted every time you change your password. bfranklin touches on this above, but a good example is Apple's FileVault 2 full-disk encryption in OSX Lion. With FileVault 2, as I understand it, there's a single 128-bit encryption key for the entire encrypted volume. Lion lets you designate specific users who can boot the encrypted system volume, and each one has to enter their password when they're added to the list. It then stores a separate copy of the encryption key for each user on the disk, encrypted with that user's password (or a derived key). It also stores one additional copy of the key, encrypted with the "recovery key", a randomly-generated string of characters that Lion gives to you when you first encrypt the volume. When the system boots, the boot loader asks for one of the authorized users to enter their password, at which point it uses the password to decrypt the volume encryption key, and then uses the key to decrypt the volume (or rather, to decrypt/encrypt any block that it needs to read or write) so the system can boot. Of course, you can also use the recovery key (which is not stored anywhere, although you can opt to let Apple keep a copy for you) to decrypt that extra copy of the volume key if needed. Of course, whenever a user changes their password, the system needs to decrypt and re-encrypt the stored copy of the volume encryption key for that user, but that's a much smaller task than doing the same thing for the entire contents of the volume.

Additionally, your wording is a little ambiguous. Brute forcing the key is expensive because decryption is expensive (checking that first encrypted block to see if the header is correct), not because deriving the key from the password is expensive. this is exactly back to front. decrypting the data is computationally cheap - we want access to the data to be fast. deriving the key from your password is computationally expensive - you only do it once each time you access your data, so it doesn't matter if it takes a while, and if it's slow then it slows down brute force searches of the password space. see http://en.wikipedia.org/wiki/PBKDF2 and http://en.wikipedia.org/wiki/Key_stretching.

Indeed, you are right Russ. Oddly, I know that, I know I knew it last night, and I'm staring at my own comment wondering how the hell I wrote that. I blame pre-baby stress.