Adding Server-Side TLS 1.0 Support - Implementing SSL/TLS Using Cryptography and PKI - page 401

This whole structure is bit-string encoded, encrypted, and wrapped up in
the fi nal, third, ASN.1 structure shown in Figure 7-2 that indicates the encryp-
tion method used and enough information to decrypt it before processing. This
section bears a bit more explanation.
Recall from Chapter 2 that you examined examples of symmetric encryption
where a passphrase such as “password” or “encrypt_thisdata” was used as a
key input to the encryption algorithms. However, using human-readable text
such as this is actually a bad idea when you want to protect data. An attacker
knows that the keyspace is limited to the printable-ASCII character set that the
user can type on the keyboard. However, you can't exactly require your users
to type characters not available on their keyboards either. PKCS #5 describes a
solution to this conundrum called password-based encryption (PBE). The idea here
is to take the user's input and feed it into a one-way hash function to securely
generate a key whose bits are far better distributed than the limited range of
the available printable-ASCII character set.
By itself, this doesn't accomplish anything, though. An attacker can still eas-
ily mount a dictionary attack on the one-way hash function; the rainbow tables
examined in Chapter 4 are perfect for this. Not only is the user's typed input
fed into the hash function to generate the keying material, a salt is added to this
to thwart dictionary attacks.
However, as you recall, salts/initialization vectors must be distributed non-
securely so that both sides know what they are, and PKCS #5 is no exception.
Therefore, a determined attacker (and remember we're talking about protecting
the keys to the kingdom — the server's private key — here) could still mount a
dictionary attack using the unencrypted salt value. He couldn't take advantage
of a pre-computed rainbow table, but still, the input space of printable-ASCII
characters is far smaller than the entire space of potential hash inputs. Especially
considering that users generally pick bad passwords that follow the typing and
spelling conventions of their native spoken languages, the attacker can probably
mount an offl ine attack in a few weeks to a month. To slow the attacker down
a bit, PKCS #5 fi nally mandates that the output from the fi rst hash be rehashed
and the output of that hash be rehashed, over and over again, up to a specifi ed
iteration count. Typically this is a large number, in the thousands - it's not a big
deal for somebody with access to the correct passphrase to do a few thousand
hashes, but it is a big deal for an attacker who has a large key space to search
through. Finally, after all that hashing, the key material is taken from the fi nal
resultant hash value.
The top-level PKCS #8 structure indicates what encryption algorithm was
used to encrypt the actual private key data — for instance “password-based
encryption using the MD5 hash function and the DES encryption function.” In
the case of DES with MD5, because MD5 produces 16 bytes of output, the DES
key is the fi rst eight bytes of this output, and the initialization vector is the last
eight bytes.