I once reviewed some C++ source code that called the C run-time rand function to create a random password. The problem with rand, as implemented in most C run-time libraries, is its predictability. Because rand is a simple function that uses the last generated number as the seed to create the next number, it can make a password derived from rand easy to guess. The code that defines rand looks like the following, from the Rand.c file in the Microsoft Visual C++ 7 C Run-time (CRT) source code. I’ve removed the multithreaded code for brevity.

int __cdecl rand (void) {
    return(((holdrand =  
             holdrand * 214013L + 2531011L)  >> 16) & 0x7fff);
}

Here’s a version documented in ??? of Brian Kernighan and Dennis Ritchie’s classic tome The C Programming Language, Second Edition (Prentice Hall PTR, 1988):

unsigned long int next = 1;
int rand(void) 
{
    next = next * 1103515245 + 12345;
    return (unsigned int)(next/65536) % 32768;
}

This type of function is common and is referred to as a linear congruential function.

A good random number generator has three properties: it generates evenly distributed numbers, the values are unpredictable, and it has a long and complete cycle (that is, it can generate a large number of different values and all of the values in the cycle can be generated). Linear congruential functions meet the first property but fail the second property miserably! In other words, rand produces an even distribution of numbers, but each next number is highly predictable! Such functions cannot be used in secure environments. Some of the best coverage of linear congruence is in Donald Knuth’s The Art of Computer Programming, Volume 2: Seminumerical Algorithms (Addison-Wesley, 1998). Take a look at the following examples of rand-like functions:

‘ A VBScript example
‘ Always prints 73 22 29 92 19 89 43 29 99 95 on my computer.
‘ Note: The numbers may vary depending on the VBScript version. 
Randomize 4269
For i = 0 to 9
    r = Int(100 * Rnd) + 1
    WScript.echo(r)
Next

//A C/C++ Example
//Always prints 52 4 26 66 26 62 2 76 67 66 on my computer.
#include <stdlib.h>
void main() {
    srand(12366);
    for (int i = 0; i < 10; i++) {
        int i = rand() % 100;
        printf("%d ", i);
    }
}

# A Perl 5 Example
# Always prints 86 39 24 33 80 85 92 64 27 82 on my computer.
srand 650903;
for (1 .. 10) {
    $r = int rand 100;
    printf "$r ";
}

//A C# example
//Always prints 39 89 31 94 33 94 80 52 64 31 on my computer.
using System;
class RandTest {
    static void Main() {
        Random rnd = new Random(1234);
        for (int i = 0; i < 10; i++) {
            Console.WriteLine(rnd.Next(100));
        }
    }
}

As you can see, these functions are not random—they are highly predictable. (Note that the numbers output by each code snippet might change with different versions of operating system or the run-time environment, but they will always remain the same values so long as the underlying environment does not change.)

Probably the most famous attack against predictable random numbers is against an early version of Netscape Navigator. In short, the random numbers used to generate the Secure Sockets Layer (SSL) keys were highly predictable, rendering SSL encryption useless. If an attacker can predict the encryption keys, you may as well not bother encrypting the data! The story originally broke on BugTraq and can be read at http://online.securityfocus.com/archive/1/3791.

Here’s another example. Interestingly, and perhaps ironically, there was a bug in the way the original CodeRed worm generated "random" computer IP addresses to attack. Because they were predictable, every computer infected by this worm attacked the same list of "random" IP addresses. Because of this, the worm ended up reinfecting the same systems multiple times! You can read more about this at http://www.avp.ch/avpve/worms/iis/bady.stm.

Another great example of a random number exploit was against ASF Software’s Texas Hold ’Em Poker application. Reliable Software Technologies—now Cigital, http://www.cigital.com—discovered the vulnerability in late 1999. This "dealer" software shuffled cards by using the Borland Delphi random number function, which is simply a linear congruential function, just like the CRT rand function. The exploit required that five cards from the deck be known, and the rest of the deck could then be deduced! You can find more information about the vulnerability at http://www.cigital.com/news/gambling.html.

The simple remedy for secure systems is to not call rand and to call instead a more robust source of random data in Windows, such as CryptGenRandom, which has two of the properties of a good random number generator: unpredictability and even value distribution. This function, declared in WinCrypt.h, is available on just about every Windows platform, including Windows 95 with Internet Explorer 3.02 or later, Windows 98, Windows Me, Windows CE v3, Windows NT 4, Windows 2000, Windows XP, and Windows .NET Server 2003.

At a high level, the process for deriving random numbers by using ­CryptGenRandom is outlined in Figure 8-1.

Figure 8-1. High-level view of the process for creating random numbers in Windows 2000 and later. The dotted lines show the flow of optional entropy provided by the calling code.

CryptGenRandom gets its randomness, also known as system entropy, from many sources in Windows 2000 and later, including the following:

The resulting byte stream is hashed with SHA-1 to produce a 20-byte seed value that is used to generate random numbers according to FIPS 186-2 appendix 3.1. Note that the developer can provide extra entropy by providing a buffer of data. Refer to the CryptGenRandom documentation in the Platform SDK for more information about the user-provided buffer. Hence, if the user provides additional data in the buffer, this is used as an element in the witches’ brew to generate the random data. The result is a cryptographically random number generator.

You can call CryptGenRandom in its simplest form like this:

#include <windows.h>
#include <wincrypt.h>

...

HCRYPTPROV hProv = NULL;
BOOL fRet = FALSE;
BYTE pGoop[16];
DWORD cbGoop = sizeof pGoop;
if (CryptAcquireContext(&hProv,
        NULL, NULL,
        PROV_RSA_FULL,
        CRYPT_VERIFYCONTEXT))
    if (CryptGenRandom(hProv, cbGoop, &pGoop)) 
        fRet = TRUE;

    if (hProv) CryptReleaseContext(hProv, 0);

However, the following C++ class, CCryptRandom, is more efficient because the calls to CryptAcquireContext (time-intensive) and CryptReleaseContext, which create and destroy a reference to a Cryptographic Service Provider (CSP), are encapsulated in the class constructors and destructors. Therefore, as long as you do not destroy the object, you don’t need to take the performance hit of calling these two functions repeatedly.

/*
  CryptRandom.cpp
*/
#include <windows.h>
#include <wincrypt.h>
#include <iostream.h>

class CCryptRandom {
public:
    CCryptRandom();
    virtual ~CCryptRandom();
    BOOL get(void *lpGoop, DWORD cbGoop);

private:
    HCRYPTPROV m_hProv;
};

CCryptRandom::CCryptRandom() {
    m_hProv = NULL;
    CryptAcquireContext(&m_hProv,
                        NULL, NULL,
                        PROV_RSA_FULL, CRYPT_VERIFYCONTEXT);
    if (m_hProv == NULL) 
        throw GetLastError();
}

CCryptRandom::~CCryptRandom() {
    if (m_hProv) CryptReleaseContext(m_hProv, 0);
}

BOOL CCryptRandom::get(void *lpGoop, DWORD cbGoop) {
    if (!m_hProv) return FALSE;
    return CryptGenRandom(m_hProv, cbGoop,
                          reinterpret_cast<LPBYTE>(lpGoop));
}

void main() {
    try {
        CCryptRandom r;

        //Generate 10 random numbers between 0 and 99.
        for (int i=0; i<10; i++) {
            DWORD d;
            if (r.get(&d, sizeof d))
                cout << d % 100 << endl;
        }
    } catch (...) {
        //exception handling
    }
}

You can find this example code with the book’s sample files in the folder Secureco2Chapter08. When you call CryptGenRandom, you’ll have a very hard time determining what the next random number is, which is the whole point!

Also, note that if you plan to sell your software to the United States federal government, you’ll need to use FIPS 140-1–approved algorithms. As you might guess, rand is not FIPS-approved. The default versions of CryptGenRandom in Windows 2000 and later are FIPS-approved.

If you must create cryptographically secure random numbers in managed code, you should not use code like the code below, which uses a linear congruence function, just like the C run-time rand function:

//Generate a new encryption key.
byte[] key = new byte[32];
new Random().NextBytes(key);

Rather, you should use code like the following sample code in C#, which fills a 32-byte buffer with cryptographically strong random data:

using System.Security.Cryptography;
try {
    byte[] b = new byte[32];
    new RNGCryptoServiceProvider().GetBytes(b);

    //display results
    for (int i = 0; i < b.Length; i++) 
        Console.Write("{0} ", b[i].ToString("x"));

} catch(CryptographicException e) {
    Console.WriteLine(e.Message);
}

The RNGCryptoServiceProvider class calls into CryptoAPI and CryptGenRandom to generate its random data. The same code in Microsoft Visual Basic .NET looks like this:

Imports System.Security.Cryptography
Dim b(32) As Byte
Dim i As Short

Try
    Dim r As New RNGCryptoServiceProvider()
    r.GetBytes(b)
    For i = 0 To b.Length - 1
        Console.Write("{0}", b(i).ToString("x"))
    Next
Catch e As CryptographicException
    Console.WriteLine(e.Message)
End Try

If your application is written using ASP.NET, you can simply call the managed classes outlined in the previous section to generate quality random numbers. If you are using a COM-aware Web server technology, you could call into the CAPICOM v2 Utilities object, which supports a GetRandom method to generate random numbers. The code below shows how to do this from an ASP page written in Visual Basic Scripting Edition (VBScript):

<%
    set oCC = CreateObject("CAPICOM.Utilities.1")
    strRand = oCC.GetRandom(32,-1)
    ’ Now use strRand
    ’ strRand contains 32 bytes of Base64 encoded random data
%>

Note the GetRandom method is new to CAPICOM version 2; it was not present in CAPICOM version 1. You can download the latest CAPICOM from http://www.microsoft.com/downloads/release.asp?ReleaseID=39546.

Claude Shannon, a pioneer in information science, produced a research paper in 1948 titled "A Mathematical Theory of Communication" that addressed the randomness of the English language. Without going into the math involved, I can tell you that the effective bit length of a random password is log2(n^m), where n is the pool size of valid characters and m is the length of the password. The following VBScript code shows how to determine the effective bit size of a password, based on its length and complexity:

Function EntropyBits(iNumValidValues, iPwdSize)
    If iNumValidValues <= 0 Then
        EntropyBits = 0
    Else
        EntropyBits = iPwdSize * log(iNumValidValues) / log(2)
    End If
End Function

‘ Check a password made from A-Z, a-z, 0-9 (62 chars)
‘ and eight characters in length.
WScript.echo(EntropyBits(62, 8))

Here’s the same thing in C/C++:

#include <math.h>
#include <stdio.h>

double EntropyBits(double valid, double size) {
    return valid ? size * log(valid) / log(2):0;
}

void main() {
    printf("%f", EntropyBits(62, 8));
}

Let me give you an idea of how bad many passwords are. Remember that DES, considered insecure for long-lived data, uses a 56-bit key. Now look at Table 8-1 to see the available-character pool size and password length required in different scenarios to create equivalent 56-bit and 128-bit keys.

If you gather keys or passwords from users, you should consider adding information to the dialog box explaining how good the password is based on its entropy. Figure 8-2 shows an example.

Figure 8-2. An example of a password entry dialog box informing the user of the relative strength of the password the user entered.

Another great document regarding random numbers in secure applications is an Internet draft written by Donald Eastlake, Jeffrey Schiller, and Steve Crocker: "Randomness Requirements for Security," which replaces RFC 1750. This is a technical yet practical discussion of random number generation. At the time of this writing, the document had expired, but the last document name was draft-eastlake-randomness2-02. You may want to search for it using your favorite Internet search engine.

There are two classes of keys: short-term keys and long-term keys. Short-term keys are often called ephemeral keys and are used by numerous networking protocols, such as IPSec, SSL/TLS, RPC, and DCOM. The key generation management process is hidden from the application and the user.

Long-term keys are used for authentication, integrity, and nonrepudiation and can be used to establish ephemeral keys. For example, when using SSL/TLS, the server uses its private key—identified by its public key certificate—to help generate ephemeral keys for each encrypted SSL/TLS session. It’s a little more complex than this, but you get the idea.

Long-term keys are also used to protect persistent data held in databases and files, and because of their long-term nature, attackers could attempt to break the key over a long period of time. Obviously, long-term keys must be generated and protected securely. Now let’s look at some good key management practices.

Encrypted data should be protected with an appropriately long encryption key. Obviously, the shorter the key, the easier it is to attack. However, the keys used for different algorithms are attacked in different ways. For example, attacking most symmetric ciphers, such as DES and RC4, requires that the attacker try every key. However, attacking RSA (an asymmetric cipher) keys requires that the attacker attempt to derive the random values used to create the public and private keys. This is a process called factoring. Because of this, you cannot say that a 112-bit 3DES key is less secure than a 512-bit RSA key because they are attacked in different ways. In fact, in this case, a 512-bit RSA key can be factored faster than performing a brute-force attack against the 112-bit 3DES key space.

However, if you protect symmetric keys using asymmetric keys, you should use an appropriately long asymmetric key. Table 8-2, derived from an Internet draft "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys" at http://ietf.org/internet-drafts/draft-orman-public-key-lengths-05.txt, gives an idea for the key-size relationships.

This table tells us that to protect an 80-bit symmetric key using RSA, the RSA key must be at least 1228 bits. If the latter is shorter than that, it will be easier for a hacker to break the RSA key than it will to attempt a brute-force attack against the 80-bit key.

When using secret information such as cryptographic keys and passwords, you must keep the keys close to the point where they encrypt and decrypt data. The rationale is simple: highly "mobile" secrets stay secret only a short time! As a friend once said to me, "The value of a secret is inversely proportional to its availability." Or, put another way, "A secret known by many is no longer a secret!" This applies not only to people knowing a secret but also to code that uses secret data. As I mentioned earlier in this book, all code has bugs, and the more code that has access to secret data, the greater the chance the secret will be exposed to an attacker. Take a look at Figure 8-3.

Figure 8-3. Allowing keys to roam through an application and keeping keys close to the point where they are used.

The example on the left of Figure 8-3 shows the password passed from function to function and executable to executable. GetKey reads the password from a persistent store and passes the password through EncryptWithKey, Encrypt, DoWork, and ultimately to EncryptData. This is a poor design because a security flaw in any of the functions could leak the private password to an assailant armed with a debugger.

The example on the right is a better design. GetKeyHandle acquires a handle to the password and passes the handle eventually to EncryptData, which then reads the key from the persistent store. If any of the intermediate functions are compromised, the attacker has access only to the handle and not to the password directly.

/*
  ProtectKey.cpp
*/
#include "stdafx.h"
using namespace std;

//Get the symmetric exchange key used to encrypt the key.
void GetExchangeKey(HCRYPTPROV hProv, HCRYPTKEY *hXKey) {
    //The key-exchange key comes from an external source.
    HCRYPTHASH hHash; 
    BYTE bKey[16];
    if (!GetKeyFromStorage(bKey, sizeof bKey))
        throw GetLastError();

    if (!CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hHash))
        throw GetLastError();

    if (!CryptHashData(hHash, bKey, sizeof bKey, 0))   
        throw GetLastError();

    if (!CryptDeriveKey(hProv, CALG_3DES, hHash, CRYPT_EXPORTABLE, 
                        hXKey))
        throw GetLastError();
}

void main() {

    HCRYPTPROV    hProv = NULL;
    HCRYPTKEY     hKey  = NULL;
    HCRYPTKEY     hExchangeKey  = NULL;
    LPBYTE        pbKey = NULL;

    try {
        if (!CryptAcquireContext(&hProv, NULL, NULL,
                                 PROV_RSA_FULL, 
                                 CRYPT_VERIFYCONTEXT))
            throw GetLastError();

        //Generate two 3DES keys, and mark them as exportable.
        //Note: these keys are kept in CryptoAPI at this point.
        if (!CryptGenKey(hProv, CALG_3DES, CRYPT_EXPORTABLE, &hKey))
            throw GetLastError();

        //Get a key that we can use to encrypt the two 3DES keys.
        GetExchangeKey(hProv, &hExchangeKey);

        //Determine blob size.
        DWORD dwLen = 0;
        if (!CryptExportKey(hKey, hExchangeKey,
                            SYMMETRICWRAPKEYBLOB, 
                            0, pb Key, &dwLen))
            throw GetLastError();

        pbKey = new BYTE[dwLen]; //Array to hold 3DES keys
        ZeroMemory(pbKey, dwLen);
        /if(!pbKey)throwError_NOT_ENOUGH_MEMORY;
        //Now get the shrouded blob.
        if (!CryptExportKey(hKey, hExchangeKey,
            SYMMETRICWRAPKEYBLOB, 0, pbKey, &dwLen))
            throw GetLastError();

        cout << "Cool, " << dwLen 
             << " byte wrapped key is exported." 
             << endl;

        //Write shrouded key to Key.bin; overwrite if needed
        //using ostream::write() rather than operator<<,
        //as the data may contain NULLs.
        
        ofstream file("c:\keys\key.bin", ios_base::binary);
        file.write(reinterpret_cast<const char *>(pbKey ), dwLen);
        file.close();

    } catch(DWORD e) {
        cerr << "Error " << e << hex << " " << e << endl;
    }

    // Clean up.
    if (hExchangeKey)   CryptDestroyKey(hExchangeKey);
    if (hKey)           CryptDestroyKey(hKey);
    if (hProv)          CryptReleaseContext(hProv, 0);
    if (pbKey)          delete [] pbKey;
}

Using stream ciphers, you can avoid the memory management game. For example, if you encrypt 13 bytes of plaintext, you get 13 bytes of ciphertext back. However, if you encrypt 13 bytes of plaintext by using DES, which encrypts using a 64-bit block size, you get 16 bytes of ciphertext back. The remaining three bytes are padding because DES can encrypt only full 64-bit blocks. Therefore, when encrypting 13 bytes, DES encrypts the first eight bytes and then pads the remaining five bytes with three bytes, usually null, to create another eight-byte block that it then encrypts. Now, I’m not saying that developers are lazy, but, frankly, the more you can get away with not having to get into memory management games, the happier you may be!

People also use stream ciphers because they are fast. RC4 is about 10 times faster than DES in software, all other issues being equal. As you can see, good reasons exist for using stream ciphers. But pitfalls await the unwary.

First, stream ciphers are not weak; many are strong and have withstood years of attack. Their weakness stems from the way developers use the algorithms, not from the algorithms themselves.

Note that each unique stream-cipher key derives the same key stream. Although we want randomness in key generation, we do not want randomness in key stream generation. If the key streams were random, we would never be able to find the key stream again, and hence, we could never decrypt the data. Here is where the problem lies. If a key is reused and an attacker can gain access to one ciphertext to which she knows the plaintext, she can XOR the ciphertext and the plaintext to derive the key stream. From now on, any plaintext encrypted with that key can be derived. This is a major problem.

Actually, the attacker cannot derive all the plaintext of the second message; she can derive up to the same number of bytes that she knew in the first message. In other words, if she knew the first 23 bytes from one message, she can derive the first 23 bytes in the second message by using this attack method.

To prove this for yourself, try the following CryptoAPI code:

/*
  RC4Test.cpp
*/
#define MAX_BLOB 50
BYTE bPlainText1[MAX_BLOB];
BYTE bPlainText2[MAX_BLOB];
BYTE bCipherText1[MAX_BLOB];
BYTE bCipherText2[MAX_BLOB];
BYTE bKeyStream[MAX_BLOB];
BYTE bKey[MAX_BLOB];

//////////////////////////////////////////////////////////////////
//Setup -  set the two plaintexts and the encryption key.
void Setup() {
    ZeroMemory(bPlainText1, MAX_BLOB);
    ZeroMemory(bPlainText2, MAX_BLOB);
    ZeroMemory(bCipherText1, MAX_BLOB);
    ZeroMemory(bCipherText2, MAX_BLOB);
    ZeroMemory(bKeyStream, MAX_BLOB);
    ZeroMemory(bKey, MAX_BLOB);

    strncpy(reinterpret_cast<char*>(bPlainText1),
        "Hey Frodo, meet me at Weathertop, 6pm.", MAX_BLOB-1);

    strncpy(reinterpret_cast<char*>(bPlainText2),
        "Saruman has me prisoner in Orthanc.", MAX_BLOB-1);

    strncpy(reinterpret_cast<char*>(bKey),
        GetKeyFromUser(), MAX_BLOB-1);                            //  External function
}

//////////////////////////////////////////////////////////////////
//Encrypt - encrypts a blob of data using RC4.
void Encrypt(LPBYTE bKey, 
             LPBYTE bPlaintext,
             LPBYTE bCipherText, 
             DWORD dwHowMuch) {
                 HCRYPTPROV hProv;
                 HCRYPTKEY  hKey;
                 HCRYPTHASH hHash;

    /*
      The way this works is as follows:
      Acquire a handle to a crypto provider.
      Create an empty hash object.
      Hash the key provided into the hash object.
      Use the hash created in step 3 to derive a crypto key. This key 
      also stores the algorithm to perform the encryption.
      Use the crypto key from step 4 to encrypt the plaintext.
    */

    DWORD dwBuff = dwHowMuch;
    CopyMemory(bCipherText, bPlaintext, dwHowMuch);
    if (!CryptAcquireContext(&hProv, NULL, NULL, PROV_RSA_FULL, 
                             CRYPT_VERIFYCONTEXT))
        throw;
    if (!CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash))
        throw;
    if (!CryptHashData(hHash, bKey, MAX_BLOB, 0))
        throw;
    if (!CryptDeriveKey(hProv, CALG_RC4, hHash, 
                        CRYPT_EXPORTABLE, 
                        &hKey))
        throw;
    if (!CryptEncrypt(hKey, 0, TRUE, 0, 
                      bCipherText, 
                      &dwBuff, 
                      dwHowMuch))
        throw;

    if (hKey)  CryptDestroyKey(hKey);
    if (hHash) CryptDestroyHash(hHash);
    if (hProv) CryptReleaseContext(hProv, 0);
}

void main() {
    Setup();

    //Encrypt the two plaintexts using the key, bKey.
    try {
        Encrypt(bKey, bPlainText1, bCipherText1, MAX_BLOB);
        Encrypt(bKey, bPlainText2, bCipherText2, MAX_BLOB);
    } catch (...) {
        printf("Error - %d", GetLastError());
        return;
    }

    //Now do the "magic."
    //Get each byte from the known ciphertext or plaintext.
    for (int i = 0; i < MAX_BLOB; i++) {
        BYTE c1 = bCipherText1[i];        //Ciphertext #1 bytes
        BYTE p1 = bPlainText1[i];         //Plaintext #1 bytes
        BYTE k1 = c1 ^ p1;                //Get keystream bytes.
        BYTE p2 = k1 ^ bCipherText2[i];   //Plaintext #2 bytes

        // Print each byte in the second message.
        printf("%c", p2);
    }
}

You can find this example code with the book’s sample files in the folder Secureco2Chapter08. When you run this code, you’ll see the plaintext from the second message, even though you knew the contents of the first message only!

In fact, it is possible to attack stream ciphers used this way without knowing any plaintext. If you have two ciphertexts, you can XOR the streams together to yield the XOR of the two plaintexts. And it’s feasible to start performing statistical frequency analysis on the result. Letters in all languages have specific occurrence rates or frequencies. For example, in the English language, E, T, and A are among the most commonly used letters. Given enough time, an attacker might be able to determine the plaintext of one or both messages. (In this case, knowing one is enough to know both.)

My first thought is that if you must use the same key more than once, you need to revisit your design! That said, if you absolutely must use the same key when using a stream cipher, you should use a salt and store the salt with the encrypted data. A salt is a value, selected at random, sent or stored unencrypted with the encrypted message. Combining the key with the salt helps foil attackers.

Salt values are perhaps most commonly used in UNIX-based systems, where they are used in the creation of password hashes. Password hashes were originally stored in a plaintext, world-readable file (/etc/passwd) on those systems. Anyone could peruse this file and compare his or her own password hash with those of other users on the system. If two hashes matched, the two passwords were the same! Windows does not salt its passwords, although in Windows 2000 and later the password hashes themselves are encrypted prior to permanent storage, which has the same effect. This functionality, known as Syskey, is optional (but highly recommended) on Windows NT 4.0 Service Pack 3 and later.

You can change the CryptoAPI code, shown earlier in "The Pitfalls of Stream Ciphers," to use a salt by making this small code change:

if (!CryptCreateHash(hProv, CALG_MD5, 0, 0, &hHash))
    throw;
if (!CryptHashData(hHash, bKey, MAX_BLOB,0))
    throw;
if (!CryptHashData(hHash, bSalt, cbSaltSize, 0))
    throw;
if (!CryptDeriveKey(hProv, CALG_RC4, 
                    hHash, CRYPT_E XPORTABLE, 
                    &hKey))
    throw;

This code simply hashes the salt into the key; the key is secret, and the salt is sent with the message unencrypted.

You can prevent bit-flipping attacks by using a digital signature or a keyed hash (explained shortly). Both of these technologies provide data-integrity checking and authentication. You could use a hash, but a hash is somewhat weak because the attacker can change the data, recalculate the hash, and add the new hash to the data stream. Once again, you have no way to determine whether the data was modified.

If you choose to use a hash, keyed hash, or digital signature, your encrypted data stream changes, as shown in Figure 8-5.

Figure 8-5. Stream cipher–encrypted data, with and without integrity checking.

As I’ve already mentioned, you can hash the data and append the hash to the end of the encrypted message, but this method is not recommended because an attacker can simply recalculate the hash after changing the data. Using keyed hashes or digital signatures provides better protection against tampering.

Creating a Keyed Hash

A keyed hash is a hash that includes some secret data, data known only to the sender and recipients. It is typically created by hashing the plaintext concatenated to some secret key or a derivation of the secret key. Without knowing the secret key, you could not calculate the proper keyed hash.

Note

A keyed hash is one kind of message authentication code (MAC). For more information, see "What Are Message Authentication Codes" at http://www.rsasecurity.com/rsalabs/faq/2-1-7.html.

The diagram in Figure 8-6 outlines how a keyed-hash encryption process operates.

Figure 8-6. Encrypting a message and creating a keyed hash for the message.

Developers make a number of mistakes when creating keyed hashes. Let’s look at some of these mistakes and then at how to generate a keyed hash securely.

Forgetting to use a key

Not using a key whatsoever when using a keyed hash is a surprisingly common mistake—this is as bad as creating only a hash! Do not fall into this trap.

Using the same key to encrypt data and key-hash data

Another common mistake, because of its ease, is using the same key to encrypt data and key-hash data. When you encrypt data with one key, K₁, and key-hash the data with another, K₂, the attacker must know K₁ to decrypt the data and must know K₂ to change the data. If you encrypt and key-hash the data with K₁ only, the attacker need only determine one key to decrypt and tamper with the data.

Basing K₂ on K₁

In some cases, developers create subsequent keys by performing some operation, such as bit-shifting it, on a previous key. Remember: if you can easily perform that operation, so can an attacker!

/*
  MAC.cpp
*/
#include "stdafx.h"
DWORD HMACStuff(void *szKey, DWORD cbKey, 
                void *pbData, DWORD cbData,
                LPBYTE *pbHMAC, LPDWORD pcbHMAC) {

    DWORD dwErr = 0;
    HCRYPTPROV hProv;
    HCRYPTKEY hKey;
    HCRYPTHASH hHash, hKeyHash;

    try {
        if (!CryptAcquireContext(&hProv, 0, 0,
            PROV_RSA_FULL, CRYPT_VERIFYCONTEXT)) 
            throw;
      
        //Derive the hash key.
        if (!CryptCreateHash(hProv, CALG_SHA1, 0, 0, &hKeyHash))
            throw;

        if (!CryptHashData(hKeyHash, (LPBYTE)szKey, cbKey, 0))
            throw;

        if (!CryptDeriveKey(hProv, CALG_DES,
            hKeyHash, 0, &hKey))
            throw;

        //Create a hash object.
        if(!CryptCreateHash(hProv, CALG_HMAC, hKey, 0, &hHash))
            throw;    

        HMAC_INFO hmacInfo;
        ZeroMemory(&hmacInfo, sizeof(HMAC_INFO));
        hmacInfo.HashAlgid = CALG_SHA1;
    
        if(!CryptSetHashParam(hHash, HP_HMAC_INFO, 
                             (LPBYTE)&hmacInfo, 
                              0)) 
            throw;   
 
        //Compute the HMAC for the data.
        if(!CryptHashData(hHash, (LPBYTE)pbData, cbData, 0))
            throw;

        //Allocate memory, and get the HMAC.
        DWORD cbHMAC = 0;
        if(!CryptGetHashParam(hHash, HP_HASHVAL, NULL, &cbHMAC, 0))
            throw;

        //Retrieve the size of the hash. 
        *pcbHMAC = cbHMAC;
        *pbHMAC = new BYTE[cbHMAC];
        if (NULL == *pbHMAC)
            throw;

        if(!CryptGetHashParam(hHash, HP_HASHVAL, *pbHMAC, &cbHMAC, 0))
            throw;
    SetLastError()
    } catch(...) {
        dwErr = GetLastError();
        printf("Error - %d
", GetLastError());
    }

    if (hProv)      CryptReleaseContext(hProv, 0);
    if (hKeyHash)   CryptDestroyKey(hKeyHash);
    if (hKey)       CryptDestroyKey(hKey);
    if (hHash)      CryptDestroyHash(hHash);

    return dwErr;
}

void main() {
    //Key comes from the user.
    char *szKey = GetKeyFromUser();
    DWORD cbKey = lstrlen(szKey);
    if (cbKey == 0) {
        printf("Error – you did not provide a key.
");
        return -1;
    }

    char *szData="In a hole in the ground...";
    DWORD cbData = lstrlen(szData);

    //pbHMAC will contain the HMAC.
    //The HMAC is cbHMAC bytes in length.
    LPBYTE pbHMAC = NULL;
    DWORD cbHMAC = 0;
    DWORD dwErr = HMACStuff(szKey, cbKey,
                            szData, cbData,
                            &pbHMAC, &cbHMAC);

    //Do something with pbHMAC.

    delete [] pbHMAC;
}

HMACSHA1 hmac = new HMACSHA1();
hmac.Key = key;
byte [] hash = hmac.ComputeHash(message);

Creating a Digital Signature

Digital signatures differ from keyed hashes, and from MACs in general, in a number of ways:

• You create a digital signature by encrypting a hash with a private key. MACs use a shared session key.

• Digital signatures do not use a shared key; MACs do.

• You could use a digital signature for nonrepudiation purposes, legal issues aside. You can’t use a MAC for such purposes because more than one party shares the MAC key. Either party having knowledge of the key could produce the MAC.

• Digital signatures are somewhat slower than MACs, which are very quick.

Despite these differences, digital signatures provide for authentication and integrity checking, just as MACs do. The process of creating a digital signature is shown in Figure 8-7.

Figure 8-7. Encrypting a message and creating a digital signature for the message.

Anyone who has access to your public key certificate can verify that a message came from you—or, more accurately, anyone who has your private key! So you should make sure you protect the private key from attack.

CAPICOM offers an incredibly easy way to sign data and to verify a digital signature. The following VBScript code signs some text and then verifies the signature produced by the signing process:

strText = "I agree to pay the lender $42.69."
Set oDigSig = CreateObject("CAPICOM.SignedData")
oDigSig.Content = strText
fDetached = TRUE
signature = oDigSig.Sign(Nothing, fDetached)
oDigSig.Verify signature, fDetached

Note a few points about this code. Normally, the signer would not verify the signature once it is created. It’s usually the message recipient who determines the validity of the signature. The code produces a detached signature, which is just the signature and not a message and the signature. Finally, this code will use or prompt the user to select a valid private key with which to sign the message.

Digital signatures are a breeze in the .NET Framework. However, if you want to access a certificate a private key stored by CryptoAPI, you’ll need to call CryptoAPI or CAPICOM directly from managed code because the System.Security.Cryptography.X509Certificates does not interoperate with CryptoAPI stores. A great example of how to do this appears in .NET Framework Security (Addison-Wesley Professional, 2002). (Details of the book are in the bibliography.) This book is a must-read for anyone doing security work with the .NET Framework and the common language runtime.

Important

When hashing, MACing or signing data, make sure you include all sensitive data in the result. Any data not covered by the hash can be tampered with, and may be used as a component of a more complex attack.

Important

Use a MAC or a digital signature to verify that encrypted data has not been tampered with.