Problem - Kevin Tafuro

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) twice with a single key.
Use a secure random value or a counter. See Recipe 4.9 for more information on
nonces.
Now we can add data as we get it using the spc_ofb_update( ) function. This function
is particularly useful when a message arrives 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_ofb_final( ).
You’re responsible for making sure the init, update, and final calls do
not happen out of order.
The function spc_ofb_update( ) has the following signature:
int spc_ofb_update(OFB_CTX *ctx, unsigned char *in, size_t il, unsigned char *out);
This function has the following arguments:
ctx
Pointer to the SPC_OFB_CTX object associated with the current message.
in
Pointer to a buffer containing the data to be encrypted or decrypted.
il
Number of bytes contained in the input buffer.
out
Pointer to the output buffer, which needs to be exactly as long as the input
buffer.
Our implementation of this function always returns 1, but a hardwarebased
implementation might have an unexpected failure, so it’s important
to check the return value!
This API is in the spirit of PKCS #11, which provides a standard cryptographic interface
to hardware. We do this so that the above functions can have the bulk of their
implementations replaced with calls to PKCS #11–compliant hardware. PKCS #11
APIs generally pass out data explicitly indicating the length of data outputted, while
Using a Generic OFB Mode Implementation | 195
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.