Problem - Kevin Tafuro

Note that this code depends on the SPC_CFB_CTX data type and the incremental CFB
interface, both discussed in the following sections.
The incremental API
Let’s look at the SPC_CFB_CTX data type. It’s defined as:
typedef struct {
SPC_KEY_SCHED ks;
int ix;
unsigned char nonce[SPC_BLOCK_SZ];
} SPC_CFB_CTX;
The ks field is an expanded version of the cipher key (block ciphers generally use a
single key to derive multiple keys for internal use). The ix field is used to determine
how much keystream we have buffered. The nonce field is really the buffer in which
we store the input to the next encryption, and it is the place where intermediate keystream
bytes are stored.
To begin encrypting or decrypting, we need to initialize the mode. Initialization is
the same operation for both encryption and decryption:
void spc_cfb_init(SPC_CFB_CTX *ctx, unsigned char *key, size_t kl, unsigned char
*nonce) {
SPC_ENCRYPT_INIT(&(ctx->ks), key, kl);
spc_memset(key,0, kl);
memcpy(ctx->nonce, nonce, SPC_BLOCK_SZ);
ctx->ix = 0;
}
Note again that we remove the key from memory during this operation.
Never use the same nonce (often called an IV in this context; see Recipe 4.9) twice
with a single key. To implement that recommendation effectively, never reuse a key.
Alternatively, pick a random starting IV each time you key, and never output more
than about 2 40 blocks using a single key.
Now we can add data as we get it using the spc_cfb_encrypt_update( ) or spc_cfb_
decrypt_update( ) function, as appropriate. These functions are particularly useful
when a message may arrive in pieces. You’ll get the same results as if it all arrived at
once. When you want to finish encrypting or decrypting, call spc_cfb_final( ).
You’re responsible for making sure the proper init, update, and final
calls are made, and that they do not happen out of order.
Using a Generic CFB Mode Implementation | 189
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.