Directions for crypto make_checksum/verify_checksum

[Tom Yu]

Greg Hudson <ghudson at MIT.EDU> writes:

> On Mon, 2009-12-07 at 12:34 -0500, ghudson at MIT.EDU wrote:
>> Note that cbc_checksum would have to allocate a temporary buffer to
>> store the encrypted output in order to compute the resulting ivec,
>> which is less efficient than the current mechanism of computing descbc
>> checksums.  I think that's a small price to pay for a smaller module
>> SPI footprint, since I don't think the descbc checksum type gets any
>> significant use.
>
> I thought up two additional concerns about this:
>
> 1. descbc would actually have to copy a whole iov array (to avoid
> modifying the caller's data by encrypting in place), which we've so far
> managed to avoid the need for everywhere else in the code.
>
> 2. I just looked at Luke's aes-ccm branch, and the same issue is going
> to come up for aescbc checksums if we go in that direction.
>
> I am currently thinking of extending the enc provider structure to
> include an ECB block encryption function, to be implemented by any enc
> provider which is used for CBC keyhashes.

Why not make an enc provider structure member that is a CBC-MAC
function?  Some back ends have CBC-MAC functions that are likely to
perform better than iterating over calling the block encryption
function.