On Thu, Dec 17, 2020 at 11:25 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > Move the boilerplate code for setkey(), init(), update(), and final() > from blake2s_generic.ko into a new module blake2s_helpers.ko, and export > it so that it can be used by other shash implementations of BLAKE2s. > > setkey() and init() are exported as-is, while update() and final() have > a blake2s_compress_t function pointer argument added. This allows the > implementation of the compression function to be overridden, which is > the only part that optimized implementations really care about. > > The helper functions are defined in a separate module blake2s_helpers.ko > (rather than just than in blake2s_generic.ko) because we can't simply > select CRYPTO_BLAKE2B from CRYPTO_BLAKE2S_X86. Doing this selection > unconditionally would make the library API select the shash API, while > doing it conditionally on CRYPTO_HASH would create a recursive kconfig > dependency on CRYPTO_HASH. As a bonus, using a separate module also > allows the generic implementation to be omitted when unneeded. > > These helper functions very closely match the ones I defined for > BLAKE2b, except the BLAKE2b ones didn't go in a separate module yet > because BLAKE2b isn't exposed through the library API yet. > > Finally, use these new helper functions in the x86 implementation of > BLAKE2s. (This part should be a separate patch, but unfortunately the > x86 implementation used the exact same function names like > "crypto_blake2s_update()", so it had to be updated at the same time.) There's a similar situation happening with chacha20poly1305 and with curve25519. Each of these uses a mildly different approach to how we split things up between library and crypto api code. The _helpers.ko is another one. There any opportunity here to take a more unified/consistant approach? Or is shash slightly different than the others and benefits from a third way? Jason
