Most efforts to break encryption eventually come down to “brute force” approaches—simply trying every possible key value until one fits. Encryption’s effectiveness usually depends on the huge range of possible keys values to make the chore of guessing take so long as to be impractical.
Many strong encryption algorithms are much stronger in theory than they turn out to be when implemented in software, because the programmer slips up and introduces less randomness in a key value by using pseudo-random (more predictable) computer-generated sources for key values or parts of key values. Such mistakes result in less work required to crack the resulting encryption, because the possible range of key values has been reduced.
Another somewhat more sophisticated version of “brute force” attack uses educated guesses to attempt to narrow down the key value. For example, someone could begin guessing a password by using a person’s first and last names, then spouse’s name, then pet’s name, and continuing with other common sources for passwords. In the case of encrypted e-mail, eliminating predictable headers (for example, “Dear Sue,”), and footers (“later, Joe”) and compressing blank space (and perhaps also removing the carriage-returns and line feeds!) goes a long way toward tightening up the plain text and making it harder for such attacks to gain an easy foothold.
Remember, too, that any encryption scheme is only as strong as its weakest link. It does no good to have an extremely fancy encryption scheme when the decryption keys, for example, are not safeguarded. When saving a key value along with encrypted data, how do you encrypt the key itself? It doesn’t hurt to use even stronger encryption for the key value and to store the key at a random location in the file, or even vary the length of the key used.
Finally, keep in mind that, as the saying goes, there is more than one way to skin a cat. If attackers cannot get in through the front door, they may resort to the back door, side door, or window, or even rip themselves a hole in your system. Consider the case of a sophisticated encryption algorithm that is snugly packed away in a nice DLL, ActiveX control, or some other dynamic (or even static) code library. If a function in this library takes passwords or key values, or stores them by calling another function, couldn’t someone simply replace the code library with his own, or (less likely in Windows NT) even intercept or “hook” a function that gets called? The moral is that you should be very, very careful at each stage of the designing and implementation process. Make sure that you haven’t inadvertently left a gaping hole.
If all this talk about security and encryption sounds too paranoid for you, then perhaps your system really doesn’t have a need for security. But I’ll bet even then you would agree on this point: Security is one area where, if you need it at all, it only makes sense to do it right. The demos discussed in this chapter—FileUser, Encrypt, and Decrypt—will give you a good start on designing your own secure applications.
In the next chapter, we’ll talk about a subject of interest to nearly every modern application developer: Internet support for your applications. This is certainly an area where you may need to use security for your applications.