Programming Convenience

A PBE program will do its work, even with the wrong password. Suppose the wrong password were entered, the program would have no way of knowing it was an incorrect password. It would simply mix the “bad” value with the salt and produce a KEK. It wouldn’t be the correct KEK, but the

Password Salt Pao-Chi's password PBE engine KEK KEK Password Salt Gwen's password PBE engine To: From sales quarter Session key Using a session key for bulk data and protecting it with PBE means that users don’t have to share passwords

program wouldn’t know that; it just blindly follows instructions. It would then use that KEK to decrypt the session key. That would work; some value would come out as a result. It would be the wrong value, but there would be something there. Then the program would use this supposed ses- sion key to decrypt the ciphertext. The resulting data would be gibberish, but only then would it be possible to see that something went wrong.

Chapter 3

60

To: From: Sales

quarter From:To:

Sales quarter Password Salt Encrypt engine Session key Ray attacks password To: From: Sales ? Password Salt Ray has to find the PBE protected session key to attack the password

Encrypt engine Ray attacks session key Figure 3-5 If Pao-Chi uses PBE to protect bulk data, Ray can recover it by breaking the password. If Pao- Chi uses PBE to protect the session key, Ray must find the encrypted key

correct password or not. That would be better than decrypting the entire bulk data before finding that out.

One solution is to use the KEK to encrypt the session key along with something else, the “something else” being some recognizable value, such as the salt. Then when decrypting, the program checks this recognizable value first. If it’s correct, continue using the session key to decrypt the bulk data. If not, the password was wrong and the process should start over.

The overall process looks like this. To encrypt bulk data:

1. Generate a random or pseudo-random session key. Use this key to encrypt the data.

2. Enter the password, generate a salt, and mix the two together to produce the KEK.

3. Encrypt the salt and session key using the KEK. Store the encrypted data with the salt.

4. Store the encrypted session key, which is actually the session key and the salt (see Figure 3-6).

To decrypt the data, follow these steps.

1. Collect the salt and password and mix the two together to produce what is presumably the KEK.

2. Using this KEK, decrypt the session key. The result is really the session key and the salt.

3. Check the decrypted salt. Is it correct?

a. If it is not correct, don’t bother using the generated session key to decrypt the data; it’s not the correct value. The user probably entered the wrong password. Go back to step 1.

b. If it is correct, use the session key to decrypt the data.

Instead of the salt, you can use a number of things as a check. For example, it could be an eight-byte number, the first four bytes being a ran- dom value and the second four, that random value plus 1. When decrypt- ing, check the first eight bytes; if the second four bytes is the first four plus 1, it’s the correct password. This may be more palatable than the salt, since if the salt is the check, there is now some known plaintext. Presum- ably, the cipher is immune to a known-plaintext attack, but nonetheless,

some people might feel it is more secure without any known plaintext. Of course, it is possible to use the wrong password and get a KEK that decrypts the check into a different eight-byte value that by sheer coinci- dence passes the test. The chances of this happening are so small, it will probably never happen in a million years.

Another check could be an algorithm identifier. This would be some sequence of bytes that represents the algorithm being used. Or it could be a combination of some of these values. In the real world, you’ll probably find that engineers come up with complex procedures that include mul- tiple checks. In these schemes, maybe one check accidentally passes, but not all of them.

Chapter 3

62

PBE Encrypt engine

Protected key and salt

Protected key

and salt Decrypt

engine Password Salt KEK KEK Password Salt Figure 3-6 Use a KEK to encrypt the session key along with a

recognizable value such as the salt. Entering the wrong password produces the wrong KEK/salt combination

Our attacker (who we’re calling Ray) has two ways to break PBE. First, he could break it like any symmetric-key encryption and use brute-force on the KEK. Second, he could figure out what the password is.

Although the KEK is the result of mixing together the password and salt, Ray doesn’t have to bother with those things; he could simply perform a brute-force attack on the KEK, use it to decrypt the session key, and then decrypt the data. This might be plausible if the session key is larger than the KEK. In Chapter 2, though, we saw that if a key is large enough, that’s not going to happen. Hence, Ray will probably try the second way, which is to figure out what the password is. Once he has the password, he can reconstruct the key-generating process and have the KEK.

How can Ray figure out what the password is? One way would be to try every possible keystroke combination. This would be another flavor of the brute-force attack. If Pao-Chi entered the password from the keyboard, Ray could try every possible one-character password. Then he would try every two-character combination (AA, AB, AC, AD, . . . ), then three-char- acter values, and so on. In this way, eight-character or less passwords (on a keyboard with 96 possible values) would be approximately equivalent to a 52-bit key. Ten-character passwords are equivalent to about 65-bit keys. Another attack is for Ray to build up a dictionary of likely passwords, such as every word in the English, German, French, and Spanish lan- guages, along with common names, easy-to-type letter combinations, such as “qwertyuiop.” He could add to that dictionary lists of common pass- words that are available from hacker sites and bulletin boards (if you’ve thought of a password, someone else probably thought of it also). When confronted with PBE, he runs through the dictionary. For each entry, he mixes it with the salt and generates an alleged KEK. He tries that KEK on the chunk of PB-encrypted data. Did it produce the session key? Because the original PBE probably has a check in it (such as the salt encrypted along with the session key), it’s probably easy to determine. If the check passes, that was the correct password and it produced the cor- rect KEK, which in turn will properly decrypt the session key, which will then decrypt the bulk data.

This dictionary attack tries fewer passwords than does the brute force attack. Any password the dictionary attack tries, the brute force attack also tries, but the brute-force attack tries many additional passwords that the dictionary attack does not. As a result, the dictionary attack is faster than the brute force attack.

Of course, if Pao-Chi comes up with a password not in Ray’s dictionary, it will never succeed. If Ray is smart, he’ll probably start with a dictionary attack and if that fails, move on to a modified brute-force attack.