Directions for crypto make_checksum/verify_checksum
tlyu at MIT.EDU
Wed Dec 9 15:57:34 EST 2009
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
More information about the krbdev