mbedtls_camellia_crypt_cbc() function

The CAMELLIA context to use. This must be initialized and bound to a key.

The mode of operation. This must be either #MBEDTLS_CAMELLIA_ENCRYPT or #MBEDTLS_CAMELLIA_DECRYPT.

The length in Bytes of the input data \p input. This must be a multiple of \c 16 Bytes.

The initialization vector. This must be a read/write buffer of length \c 16 Bytes. It is updated to allow streaming use as explained above.

The buffer holding the input data. This must point to a readable buffer of length \p length Bytes.

The buffer holding the output data. This must point to a writable buffer of length \p length Bytes.

Initialize a CAMELLIA context.

Clear a CAMELLIA context.

Perform a CAMELLIA key schedule operation for encryption.

Perform a CAMELLIA key schedule operation for decryption.

Perform a CAMELLIA-ECB block encryption/decryption operation.

Perform a CAMELLIA-CFB128 buffer encryption/decryption operation.

Perform a CAMELLIA-CTR buffer encryption/decryption operation. *note Due to the nature of CTR mode, you should use the same key for both encryption and decryption. In particular, calls to this function should be preceded by a key-schedule via mbedtls_camellia_setkey_enc() regardless of whether the mode is #MBEDTLS_CAMELLIA_ENCRYPT or #MBEDTLS_CAMELLIA_DECRYPT. \warning You must never reuse a nonce value with the same key. Doing so would void the encryption for the two messages encrypted with the same nonce and key. There are two common strategies for managing nonces with CTR: 1. You can handle everything as a single message processed over successive calls to this function. In that case, you want to set \p nonce_counter and \p nc_off to 0 for the first call, and then preserve the values of \p nonce_counter, \p nc_off and \p stream_block across calls to this function as they will be updated by this function. With this strategy, you must not encrypt more than 2**128 blocks of data with the same key. 2. You can encrypt separate messages by dividing the \p nonce_counter buffer in two areas: the first one used for a per-message nonce, handled by yourself, and the second one updated by this function internally. For example, you might reserve the first \c 12 Bytes for the per-message nonce, and the last \c 4 Bytes for internal use. In that case, before calling this function on a new message you need to set the first \c 12 Bytes of \p nonce_counter to your chosen nonce value, the last four to \c 0, and \p nc_off to \c 0 (which will cause \p stream_block to be ignored). That way, you can encrypt at most \c 2**96 messages of up to \c 2**32 blocks each with the same key. The per-message nonce (or information sufficient to reconstruct it) needs to be communicated with the ciphertext and must be unique. The recommended way to ensure uniqueness is to use a message counter. An alternative is to generate random nonces, but this limits the number of messages that can be securely encrypted: for example, with 96-bit random nonces, you should not encrypt more than 2**32 messages with the same key. Note that for both strategies, sizes are measured in blocks and that a CAMELLIA block is \c 16 Bytes. \warning Upon return, \p stream_block contains sensitive data. Its content must not be written to insecure storage and should be securely discarded as soon as it's no longer needed.