Table of Contents for

Network Security with OpenSSL

Only two types of symmetric ciphers exist that are well-respected and see any sort of widespread use: block ciphers and stream ciphers. Block ciphers are traditionally the most popular. They operate by breaking up data into fixed-size blocks, and then encrypting each block individually, in which the encryption algorithm is a reversible function of the input. Leftover data is traditionally padded so that the length of the plaintext is a multiple of the cipher’s block size. Stream ciphers are essentially just cryptographic pseudorandom number generators. They use a starting seed as a key to produce a stream of random bits known as the keystream . To encrypt data, one takes the plaintext and simply XORs it with the keystream. Stream ciphers don’t need to be padded per se, though they are usually padded to byte-boundaries, since implementations usually operate on a per-byte level instead of a per-bit level.

The best block ciphers are a far more conservative solution than stream ciphers because they are better studied. Yet stream ciphers tend to be far faster than block ciphers. For example, RC4, currently the most popular stream cipher, runs about 4 times faster than Blowfish, which is among the fastest available block ciphers, and runs almost 15 times faster than 3DES, which is a very conservative cipher choice. AES is faster than 3DES and has more security in terms of a longer key size, but it is still generally slower than even Blowfish.

Neither block ciphers nor stream ciphers can give us perfect security , in which an attacker can never recover a message as long as the communicating parties use the algorithm properly. For each type of cipher, the security is, at best, a function of the key length. It’s always possible to launch a brute-force attack, in which the attacker tries every possible key until the message properly decrypts. If the key length is long enough, the attack will take so long on average as to be infeasible in practice.

Even if there was no better attack on an individual cipher than brute force, there are other issues that plague naive use of both types of cipher. Stream ciphers have the problem that a one-bit flip of the ciphertext causes a one-bit flip in the decrypted plaintext. Obviously, stream ciphers need to be supplemented with data integrity checks. For such purposes, we recommend message authentication codes (MACs—see Chapter 8).

When used directly, block ciphers always encrypt a given block of data in the same way, and thus do not effectively conceal patterns in a stream of data. An attacker can keep a dictionary of known plaintext blocks to known ciphertext blocks, which can often be useful in deciphering real messages. Additionally, an attacker can easily substitute one ciphertext block for another, often with great success. There are ways to use ciphers that can solve these problems to some degree, which we discuss in the next section. Additionally, MACs can be used to thwart actual modification attacks.

Stream ciphers are subject to a similar, more serious problem. Once you start encrypting using a given key, you must continue to generate new data in the keystream, or generate and exchange a new key. If you start over using the same key, the security of the stream cipher is effectively lost. The solution is to never reuse keys when using a stream cipher. Don’t even use the same key across reboots.

OpenSSL implements four common modes for block ciphers. Each of these modes can be used with every block cipher in the library, with the exception of DESX, which is defined as having only a single mode of operation.

OpenSSL provides implementations of an array of algorithms that meet most needs. The only significant lack in some versions is an implementation of the new Advanced Encryption Standard (AES). AES is supported in the long-awaited 0.9.7 release.

In addition to the actual cipher algorithms that OpenSSL provides, the null cipher is also supported, which passes data through untouched. You can access this cipher using EVP_enc_null. It is primarily useful for testing the EVP interface, so you should generally avoid using it in production systems.

Before we can begin encrypting or decrypting, we must allocate and initialize a cipher context. The cipher context is a data structure that keeps track of all relevant state for the purposes of encrypting or decrypting data over a period of time. For example, we can have multiple streams of data encrypted in CBC mode. The cipher context will keep track of the key associated with each stream and the internal state that needs to be kept between messages for CBC mode. Additionally, when encrypting with a block-based cipher mode, the context object buffers data that doesn’t exactly align to the block size until more data arrives, or until the buffer is explicitly flushed, at which point the data is usually padded as appropriate.^[1]

The generic cipher context type is EVP_CIPHER_CTX . We can initialize one, whether it was allocated dynamically or statically, by calling EVP_CIPHER_CTX_init , like so:

EVP_CIPHER_CTX *x = (EVP_CIPHER_CTX *)malloc(sizeof(EVP_CIPHER_CTX));
EVP_CIPHER_CTX_init(x);

After allocating the context object and initializing it, we must set up the cipher context. At this point, we generally determine whether the particular context will be used for encrypting or decrypting. It is possible to set up a context to do both, but it’s a bad idea in any mode other than ECB mode, because race conditions can easily occur that will desynchronize communication. Essentially, the internal cipher state of the two communicating parties needs to remain synchronized at all times. If both parties send data at the same time, they will likely end up trying to decrypt the data they receive using an incorrect state.

When we set up a cipher context, we not only choose whether we’re encrypting or decrypting, but also do the following:

EVP_EncryptInit is the preferred method for setting up a cipher context for encryption. For decryption, it is EVP_DecryptInit . Both of these methods have the same signature, which includes four parameters.

int EVP_EncryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
                    unsigned char *key, unsigned char *iv);
int EVP_DecryptInit(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *type,
                    unsigned char *key, unsigned char *iv);

Notice that the engine package prefers an extended API, EVP_EncryptInit_ex and EVP_DecryptInit_ex, which inserts a fifth argument before the key that is a pointer to the engine to use; it should be NULL when no hardware acceleration is being used. When Version 0.9.7 of OpenSSL is released, these versions of the calls will be the preferred API. When using engines, many calls can fail, so check error codes. We don’t do this because we don’t use the ENGINE API in our examples.

Let’s consider an example in which we try to encrypt using Blowfish with 128-bit keys in CBC mode. CBC mode can use an initialization vector, which is always the size of one block (in this case, 8 bytes). We will use the OpenSSL pseudorandom number generator to provide a randomly generated key; however, distributing that key is not really covered in this example. For now, we’ll assume that you will do it offline, perhaps by exchanging a disk, or reading the key over the phone (key exchange protocols are discussed in Chapter 8). To that end, we do print out the key to stdout in hexadecimal format. Note that doing this is not really the best idea for real applications. Example 6-1 shows how to do this.

#include <openssl/evp.h>

void select_random_key(char *key, int b)
{
    int i;

    RAND_bytes(key, b);
    for (i = 0;  i < b - 1;  i++)
        printf("%02X:", key[i]);
    printf("%02X\n", key[b - 1]);
}

void select_random_iv(char *iv, int b)
{
    RAND_pseudo_bytes(iv, b);
}

int setup_for_encryption(void)
{
    EVP_CIPHER_CTX ctx;
    char           key[EVP_MAX_KEY_LENGTH]; 
    char           iv[EVP_MAX_IV_LENGTH];

    if (!seed_prng(  ))
        return 0;
    select_random_key(key, EVP_MAX_KEY_LENGTH);
    select_random_iv(iv, EVP_MAX_IV_LENGTH);
    EVP_EncryptInit(&ctx, EVP_bf_cbc(  ), key, iv);
    return 1;
}

Note that multiple implementations of the seed_prng function are provided in Chapter 4. It returns 0 if the pseudorandom number generator cannot be seeded securely. We return an error status from our setup function in this case, so we don’t need to check the return value of RAND_pseudo_bytes when we call it. Also, you may want to use raw entropy. See Chapter 4 for more information.

Another thing to note is that the party decrypting the data will need to initialize its cipher context with the same initialization vector created here. Passing the initialization vector in the clear is OK, but it should probably be MAC’d so that the receiver can detect tampering. If NULL is passed in for an IV, an array filled with zeros is used. Note that IVs can be used in all modes except ECB. In ECB mode, you can still pass in an IV, but block ciphers will ignore it.

Setting up for decryption is generally easier, because we already know the key and the IV used. Example 6-2 shows how to set up for decryption under the same configuration.

#include <openssl/evp.h>

void setup_for_decryption(char *key, char *iv)
{
    EVP_CIPHER_CTX ctx;

    EVP_DecryptInit(&ctx, EVP_bf_cbc(  ), key, iv);
}

Subsequent calls to EVP_EncryptInit or EVP_DecryptInit will change the value of any non-null parameter as long as the cipher type parameter is set to NULL. Otherwise, the context is completely reinitialized. Additionally, the key and the IV can both be set to NULL on the first call to these functions, and set separately later. This is necessary when you specify a cipher and then change the key length from the default. Of course, you will need to at least provide a valid key before encryption begins.

Many ciphers take a variable key length, which can be easily set after initialization using the call EVP_CIPHER_CTX_set_key_length . For example, we can set the Blowfish key length to 64 bits, as follows:

EVP_EncryptInit(&ctx, EVP_bf_ecb(  ), NULL, NULL);
EVP_CIPHER_CTX_set_key_length(&ctx, 8);
EVP_EncryptInit(&ctx, NULL, key, NULL);

In this case, we set the key with a second call to EVP_EncryptInit after we specify the key length.

When using this functionality, make sure you only set the key length to a valid value for the cipher.

If we wish to check the default key length of a cipher object, we can use the call EVP_CIPHER_key_length . For example, the following will show us the default key length for Blowfish:

printf("%d\n", EVP_CIPHER_key_length(EVP_bf_ecb(  ));

We can also check to see the length of the keys a cipher context is using:

printf("%d\n", EVP_CIPHER_CTX_key_length(&ctx));

For other cipher parameters, OpenSSL provides a generic call, EVP_CIPHER_CTX_ctrl . Currently, this call can only set or query the effective key strength in RC2 or the number of rounds used in RC5.

int EVP_CIPHER_CTX_ctrl(EVP_CIPHER_CTX *ctx, int type, int arg, void *ptr);

For example, to query the effective key bits in an RC2 cipher context, storing the result in a variable called kb:

EVP_CIPHER_CTX_ctrl(&ctx, EVP_CTRL_GET_RC2_KEY_BITS, 0, &kb);

And to set the effective key strength of RC2 to 64 bits:

EVP_CIPHER_CTX_ctrl(&ctx, EVP_CTRL_SET_RC2_KEY_BITS, 64, NULL);

Setting and querying RC5 rounds works the same way. Remember from our previous discussion that OpenSSL is limited to 8, 12, or 16 rounds for RC5.

Another desirable option to set in a cipher context is whether padding is used. Without padding, the size of the ciphertext will always be the same size as the plaintext. On the downside, the length of the data encrypted must be an exact multiple of the block size. With padding, any length in bytes is feasible, but the resulting ciphertext can be up to a block longer than the plaintext. Unfortunately, OpenSSL versions through 0.9.6c do not allow padding to be disabled. This changes in Version 0.9.7, which has a function called EVP_CIPHER_CTX_set_padding that takes a pointer to a cipher context, and an integer that represents a Boolean value (0 for no padding, 1 for padding).

Once the c ipher context is initialized, there are two steps to encryption with the EVP interface: updating and finalization. When you have data to encrypt, you pass the data to the update function, along with a pointer to where you’d like any output to go. There may or may not be output as the result of an update. If the cipher can encrypt one or more entire blocks of data, it will do so. Any leftover data will be buffered and processed either during the next call to the update function or during the call to finalize. When calling finalize, any leftover data is padded and encrypted. If there is no leftover data, a block of pad is encrypted.^[2] As with updating, you must tell the routine where to store resulting data.

The update function is EVP_EncryptUpdate .

int EVP_EncryptUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl,
                      unsigned char *in, int inl);

When using a block-based cipher mode (ECB or CBC), the amount of output written can be both larger and smaller than the length of the input, due to internal buffering and padding. If you’re using a cipher with 8-byte (64-bit) blocks, the output could be up to 7 bytes smaller than the input, or up to 7 bytes larger.^[3] If you are encrypting incrementally with a single key, and are producing packets of data, this is good to keep in mind. If, instead, you’re encrypting to a single buffer, you will always avoid overflow by making the output buffer an entire block bigger than the input buffer (the extra block may fill with padding). Optionally, you can manually keep track of exactly how much data will be output as a function of how much data was input.

The finalization function is EVP_EncryptFinal .

int EVP_EncryptFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl);

Currently, this function always outputs. However, in the forthcoming 0.9.7 release it will not place anything in the output buffer at all if padding is turned off. In such a case, if there is any buffered data, the function returns an error. Additionally,Version 0.9.7 adds an EVP_EncryptFinal_ex call that should be used when a context has been initialized by EVP_EncryptInit_ex.

Example 6-3 shows the implementation of a function that takes a pointer to an initialized EVP cipher context, a buffer to encrypt, an associated length, and a pointer to an integer. The function then encrypts the data 100 bytes at a time into a heap-allocated buffer, which is the function’s return value. The length of the resulting ciphertext is passed back in the address specified by the final parameter.

#include <openssl/evp.h>

char *encrypt_example(EVP_CIPHER_CTX *ctx, char *data, int inl, int *rb)
{
    char *ret;
    int  i, tmp, ol;

    ol = 0;
    ret = (char *)malloc(inl + EVP_CIPHER_CTX_block_size(ctx));
    for (i = 0;  i < inl / 100;  i++)
    {
        EVP_EncryptUpdate(ctx, &ret[ol], &tmp, &data[ol], 100);
        ol += tmp;
    }
    if (inl % 100)
    {
        EVP_EncryptUpdate(ctx, &ret[ol], &tmp, &data[ol], inl%100);
        ol += tmp;
    }
    EVP_EncryptFinal(ctx, &ret[ol], &tmp);
    *rb = ol + tmp;
    return ret;
}

Factoring in the block length (done by calling EVP_CIPHER_CTX_block_size) is unnecessary when using a stream cipher, or when using the CFB or OFB cipher modes, since there is no padding in those cases. As a result, the cipher can output encrypted data as needed, without having to buffer any plaintext.^[4]

The above example works well when we can afford to encrypt everything into a single buffer before processing the ciphertext. It doesn’t work so well if we need to deal with ciphertext incrementally. For example, we might wish to send blocks of data as quickly as possible, and not wait for all data to be processed. Example 6-4 shows a solution for such a scenario. Data to be encrypted is sent to incremental_encrypt as needed. When there’s data to be sent, incremental_encrypt calls incremental_send , which is simply a stub, but it can place those blocks currently encrypted on the network. When all data to be encrypted has been passed to incremental_encrypt, then incremental_finish is called.

#include <openssl/evp.h>

int incremental_encrypt(EVP_CIPHER_CTX *ctx, char *data, int inl)
{
    char *buf;
    int  ol;
    int  bl = EVP_CIPHER_CTX_block_size(ctx);

    /* Up to the block size - 1 chars can be buffered up.  Add that to the length
     * of the input, and then we can easily determine the maximum number of
     * blocks output will take by integer divison with the block size.
     */
    buf = (char *)malloc((inl + bl - 1) / bl * bl);
    EVP_EncryptUpdate(ctx, buf, &ol, data, inl);
    if (ol)
        incremental_send(buf, ol);
    /* incremental_send must copy if it wants to store. */
    free(buf);
    return ol;
}

/* Also returns the number of bytes written. */
int incremental_finish(EVP_CIPHER_CTX *ctx)
{
    char *buf;
    int  ol;
  
    buf = (char *)malloc(EVP_CIPHER_CTX_block_size(ctx));
    EVP_EncryptFinal(ctx, buf, &ol);
    if (ol)
        incremental_send(buf, ol);
    free(buf);
    return ol;
}

Note that the number of bytes written by EVP_EncryptFinal should always be 8 when using 64-bit blocks and when padding is enabled.

As expected, the decryption API looks similar to the encryption API. After cipher initialization, two methods are involved, EVP_DecryptUpdate and EVP_DecryptFinal . You can pass as much data as you want into EVP_DecryptUpdate.

When using a block-based mode (ECB or CBC), you can pass in partial blocks of text, but EVP_DecryptUpdate will output only whole blocks. The rest will be stored until there is more data to be processed, or until EVP_DecryptFinal is called. Moreover, if the context’s cached ciphertext plus the length of the new ciphertext is exactly block-aligned, the entire final block will be held in the context instead of getting output. With CFB and OFB modes and with stream ciphers, there’s no padding, so the size of the resulting ciphertext will be equal to the size of the plaintext.

If using a block-based mode, EVP_DecryptFinal first checks to see if the padding on the last block is in the right format. If not, the function returns 0, signifying failure. Otherwise, it flushes any remaining data to the buffer passed in as the second argument, and writes the number of bytes flushed into the third argument, a reference parameter. For other modes, this call does nothing.

Example 6-5 shows a simple function that decrypts a block of encrypted text into a dynamically allocated buffer and returns it. This function can be used to incrementally decrypt, and thus requires EVP_DecryptFinal to be called when a block-based mode is used. Of course, EVP_DecryptInit should always be called before passing a context to this function.

char *decrypt_example(EVP_CIPHER_CTX *ctx, char *ct, int inl)
{
    /* We're going to null-terminate the plaintext under the assumption it's
     * non-null terminated ASCII text.  The null can be ignored otherwise.
     */
    char *pt = (char *)malloc(inl + EVP_CIPHER_CTX_block_size(ctx) + 1);
    int  ol;
  
    EVP_DecryptUpdate(ctx, pt, &ol, ct, inl);
    if (!ol) /* there's no block to decrypt */
    {
        free(pt);
        return NULL;
    }
    pt[ol] = 0;
    return pt;
}

As is the case with encryption, factoring in the cipher’s block length is strictly only necessary when using a block-based cipher mode.

Using the above function, and the ones we previously developed, let’s look at Example 6-6, which encrypts a 15-byte string using Blowfish in CBC mode, then passes it into decrypt_example in two parts. Note, we use the macro EVP_MAX_BLOCK_LENGTH, which exists only in 0.9.7 and later. If you are using an earlier version of OpenSSL, you can define this macro to the value “64”, which is the largest possible block size in 0.9.6c and earlier.

int main(int argc, char *argv[])
{
    EVP_CIPHER_CTX ctx;
    char           key[EVP_MAX_KEY_LENGTH]; 
    char           iv[EVP_MAX_IV_LENGTH];
    char           *ct, *out;
    char           final[EVP_MAX_BLOCK_LENGTH];
    char           str[] = "123456789abcdef";
    int            i;

    if (!seed_prng(  ))
    {
        printf("Fatal Error!  Unable to seed the PRNG!\n");
        abort(  );
    }

    select_random_key(key, EVP_MAX_KEY_LENGTH);
    select_random_iv(iv, EVP_MAX_IV_LENGTH);

    EVP_EncryptInit(&ctx, EVP_bf_cbc(  ), key, iv);
    ct = encrypt_example(&ctx, str, strlen(str), &i);
    printf("Ciphertext is %d bytes.\n", i);

    EVP_DecryptInit(&ctx, EVP_bf_cbc(  ), key, iv);
    out = decrypt_example(&ctx, ct, 8); 
    printf("Decrypted: >>%s<<\n", out);
    out = decrypt_example(&ctx, ct + 8, 8); 
    printf("Decrypted: >>%s<<\n", out);
    if (!EVP_DecryptFinal(&ctx, final, &i))
    {
        printf("Padding incorrect.\n");
        abort(  );
    }
    final[i] = 0;
    printf("Decrypted: >>%s<<\n", final);
}

If we run this example, the first time we try to output decrypted plaintext, we will see nothing, even though we fed the decryption routine a full block of data. Note that when we feed the remainder of the data, we are passing in eight bytes, because the encryption routine padded the data to a block-aligned length. At that point, one block will be output, and the second block will be held in reserve until there is more data, or until EVP_DecryptFinal is called.

If we were to change the cipher to RC4, the above example would compile, but give slightly incorrect output. The length of the encrypted text would be 15 bytes, not 16, due to the lack of padding. As a result, passing in 16 bytes of ciphertext to the decrypt routine will cause a block of garbage to be decrypted. Changing the third argument in the second call to decrypt_example to seven fixes the problem.

It is almost never desirable to use ECB mode for encryption. Schneier recommends it for encrypting other keys or other situations in which the data is short and random. However, this advice applies only when the key length is no larger than the cipher block length. Additionally, if you wish to include an integrity check alongside your data (which is almost always a good idea), ECB again becomes undesirable.

Another occasion when people think to use ECB is when encrypting datagrams to be sent over a UDP connection. The problem is that packets may show up out of order, or not at all. All basic cipher modes besides ECB require an ordered, reliable stream of data.

CBC mode is much better suited to handling UDP traffic. A single key can be used to encrypt all data, but each packet gets initialized with a randomly chosen IV, which can be sent alongside the encrypted data.

Counter mode is slightly better suited than CBC for encrypting UDP traffic. One advantage of counter mode over OFB and other modes that simulate stream ciphers is that it can inherently survive data loss—the current state of the counter can be passed in the clear each time a packet is sent. Another major advantage of counter mode is that it allows for parallelization, which is not supported by any of the default modes, except for ECB (a CBC-based approach could parallelize at the packet level, but could not parallelize the processing of data within a single packet). Another feature unique to OFB is that most of the work can be done offline. That is, you can generate a keystream before there is even data available to encrypt, while you have spare CPU cycles.

Additionally, because counter mode essentially supports arbitrarily jumping around a data stream, it can enable file encryption where random access to the data is still possible. Moreover, in theory, counter mode should be able to handle the UDP encryption problem without a rekey for every packet. However, current limitations of the OpenSSL library make that goal difficult to achieve, although the forthcoming 0.9.7 release will fix the problem.

OpenSSL currently doesn’t support counter mode, but it is simple to implement yourself. Counter mode effectively turns a block cipher into a stream cipher. For each block of plaintext, we encrypt a counter of exactly one block in length, which gets XOR’d with the corresponding block of plaintext. Then, the counter is incremented in some way. Increasing the counter by one or using a PRNG to increment the counter both work. The PRNG doesn’t even need to be cryptographically secure, though it must not repeat items before enumerating all possible values.

We can prevent the attacker from seeing the counter if need be. Let’s say that, in addition to an agreed-upon key, we share a second secret of the same length. Additionally, a sequence number is sent in the clear with each packet. To generate the counter used to encrypt the first data block in that packet, we concatenate the second shared secret with the sequence number, and cryptographically hash that. We show how to use cryptographic hashes in Chapter 7.

Counter mode is easily implemented by keeping track of a counter that is encrypted in ECB mode once for each block. In our UDP example, each packet would have several blocks. Only one counter should need to be sent per packet, because the receiving end should be able to recreate the counter values for the subsequent blocks.

Example 6-7 shows an implementation of counter mode that will work for any cipher in ECB mode. There is just one function, counter_encrypt_or_decrypt , as encryption and decryption are identical in counter mode.

int counter_encrypt_or_decrypt(EVP_CIPHER_CTX *ctx, char *pt, char *ct, int len,
                               unsigned char *counter);

In this example, the counter must be the same size as the block size of the cipher we’re using (we query the cipher’s block size to specify that value). Cipher block sizes are usually bigger than 32 bits, so it is best to represent the counter as an array of unsigned bytes. This function also modifies the counter in place as it processes blocks. To increment the counter, we simply increment the leftmost byte until it rolls over, at which point we increment the byte next to it, and so on. Note that it’s extremely important not to reuse counter values with a single key, not even across a reboot. If there is any chance of reusing a counter, be sure to change the key.

The next function will return -1 if it determines that the cipher is not in ECB mode (we need to use this mode in order to implement counter mode; do not take this example as an endorsement of ECB in general). This is accomplished by calling EVP_CIPHER_CTX_mode , which returns a number. If that number is equal to the constant EVP_CIPH_ECB_MODE, then we know the cipher was initialized improperly. See the documentation on the book’s web site for a list of other valid mode constants.

Note that the code in Example 6-7 should not be used without also using a MAC to provide data integrity, as discussed in Chapter 7.

int counter_encrypt_or_decrypt(EVP_CIPHER_CTX *ctx, char *pt, char *ct, int len,
              unsigned char *counter)
{
    int  i, j, where = 0, num, bl = EVP_CIPHER_CTX_block_size(ctx);
    char encr_ctrs[len + bl]; /* Encrypted counters. */

    if (EVP_CIPHER_CTX_mode(ctx) != EVP_CIPH_ECB_MODE)
        return -1;
    /* <= is correct, so that we handle any possible non-aligned data. */
    for (i = 0;  i <= len / bl;  i++)
    {
        /* Encrypt the current counter. */
        EVP_EncryptUpdate(ctx, &encr_ctrs[where], &num, counter, bl);
        where += num;
        /* Increment the counter. Remember it's an array of single characters */
        for (j = 0;  j < bl / sizeof(char);  j++)
        {
            if (++counter[j])
                break;
        }
    }
    /* XOR the key stream with the first buffer, placing the results in the
     * second buffer.
     */
    for (i = 0;  i < len;  i++)
        ct[i] = pt[i] ^ encr_ctrs[i];
    return 1; /* Success. */
}

As we discussed, the above example requires the state of the counter to be kept externally. Another option is to make a COUNTER_CTX data type that could hold a pointer to the underlying cipher context and the current state of the counter. However, this less-abstract API makes it easier to use in a situation in which the counter may need to be reset explicitly after desynchronization, such as when dealing with UDP traffic.