Expose block nature of MAC functions?

[newpavlov]

Most (if not all?) MAC constructs process messages in blocks. I think we either could add a BlockMac trait which would process messages in blocks (its state will not contain internal buffer for partially processed messages) and on top of which will be built a Mac implementation using wrapper defined in crypto-mac, or less invasive approach would be to add a trait similar to digest::BlockInput.

Exposing block nature could be helpful for RustCrypto/AEADs#74 and may reduce some amount of boilerplate if we are to follow the first option.

[tarcieri]

Sounds a bit closer to the API that UniversalHash exposes. I agree it's nice to remove that sort of intermediate buffering logic whenever possible, and so far UniversalHash has not needed it at all. I managed to remove the last of it from poly1305 in this PR:

https://github.com/RustCrypto/universal-hashes/pull/52/files#diff-5161721feffdc096d85fc7e5023453fe

Though to make xsalsa20poly1305 work, I did have to add a multi-block "unpadded" API:

RustCrypto/universal-hashes#55

I guess one thing to potentially keep in mind, both for MACs and for universal-hash, is processing multiple blocks in parallel. BlockCipher captures this well now with ParBlocks. I think both UniversalHash, and a hypothetical block-oriented MAC interface, could benefit from this as well, especially for SIMD implementations.

[newpavlov]

One deficiency of the ParBlocks approach is that its value is fixed, while SIMD accelerated code may change number of blocks processed in parallel depending on hardware capabilities. I've encountered this problem in RustCrypto/block-ciphers#135, the new version of aes-soft should have ParBlocks = U1, while AES-NI uses ParBlocks = U8, so we will not be able to implement runtime switch between them 100% correctly, since associated constant/type can not change at runtime.

[tarcieri]

Perhaps we could have an API that acts on an arbitrary sized slice of blocks?

[newpavlov]

Yes, it's a viable option, but we would have to keep in mind that ParBlocks may influence memory layout, e.g. as done in pmac. I guess we could keep ParBlocks in addition to the new API and state that it should take value of max possible parallel processing capability, it could lead to some wasted memory, but I guess there is no nice workaround for it.

[newpavlov]

Resolved in #819.